Live data from Hacker News

Researching a new form of HTTP caching optimization

blog.phusion.nl

41–50 of 50 posts

Re: Researching a new form of HTTP caching optimization

#41

> the Varnish HTTP cache has been used very successfully to speed up WordPress. But Varnish doesn’t help a lot with logged-in traffic > This is caching that Varnish and other “normal” HTTP caches (including CloudFlare) could not have done Varnish supports the ESI (Edge-Side Includes) standard, which allows it to cache fragments of a page, and for the cache server to build them again. It also allows you to completely…

Varnish also supports plugins for extreme flexibility. For example, I wrote a plugin for our Varnish install which performs HMAC validation of a specific signed cookie and then sets a header which is used downstream in the caching rules.

Varnish is mature, powerful, and fast as hell. It would take a lot of work to reach a point where I'd swap it out for something else.

Re: Researching a new form of HTTP caching optimization

#42

Earlier quoted context omitted.

Good to know. Using edge side includes may be easier than trying to change the app to a semi single page app. But that only solves half of the problem. The other half is varying the response based on the value of a specific cookie. I've updated the blog post with information regarding edge side include.

Varnish also supports custom cache keys via the VCL function `vcl_hash` as documented in https://www.varnish-software.com/static/book/VCL_functions.h... I couldn't (quickly) find documentation on how to get the value of a specific cookie, but the server could send a user ID in a header or something Varnish can easily access to be used in the above function.

Off the top of my head:

    sub vcl_recv {
      set req.http.X-Custom-Cookie-Value = regsub(req.http.cookie, ".*;|^)YOUR_COOKIE_NAME=([^;]+)(;.*|$)", "\2");
    }
Then you can just:

    sub vcl_hash {
      set req.hash += req.http.X-Custom-Cookie-Value;
    }
And now you're cache segmented on that cookie value.

Re: Researching a new form of HTTP caching optimization

#43
> Normally, non-cacheable page fragments would make every page uncacheable.

AFAICT, ASP.NET supported partial output caching since 2003. And, it can store multiple versions of a cached item via a user-defined parameter (a property on the cached control class). It seems it might be possible to simply create a property that returns the user ID and let the cache vary on that.

Of course, this uses the Web Forms controls-based system, which isn't very popular. But calling this type of caching new seems a bit of a stretch.

http://msdn.microsoft.com/en-us/library/k4he1ds5%28v=vs.71%2...

Edit: And here's a link talking about VaryByCustom, complete with example code that uses the version of the browser to generate unique per-browser-version caches.

http://msdn.microsoft.com/en-us/library/5ecf4420%28v=vs.71%2...

Re: Researching a new form of HTTP caching optimization

#44

Earlier quoted context omitted.

I understand that you want to offer something that 'beats' varnish, and it shines through in the article. But I don't think it matters if your cache is better than every other cache. Rather, as long as you offer a convenient, easily implemented cache, built into the webserver, that's great in itself. We're using Passenger on all our production servers and are most satisfied, because of its ease of use. Perhaps you co…

> I understand that you want to offer something that 'beats' varnish, and it shines through in the article. I am the author of the article. No, the point is not to "beat" Varnish. It is an article describing various ideas and a call for help. See https://news.ycombinator.com/item?id=8844905 Perhaps the writing style gave a competitive impression, so I've updated the article to mention that we're not out to beat Varni…

Everything described in the article is covered by Varnish. You can hash on Vary headers, on individual cookie values, on the sum of the digits in the user's IP address if you want. ESI lets you provide partial caching of pages as the article describes - it's actually a separate standard that's existed since 2001 (http://en.wikipedia.org/wiki/Edge_Side_Includes).

Varnish also gives us things like ACLs for managing access to various resources, on-demand content purges, multiple routable backends with different cache/grace rules, and more powerfully, request pre-processing - one thing we do is process the request and determine if the agent is capable of accepting WebP images, and if they are, we add that to the hash key with a corresponding header for the app to key on and determine whether to serve JPEG or WebP images. This lets us serve WebP images to modern agents for faster downloads, while gracefully falling back to JPEG for anything we're not sure of.

Varnish is way more than a "make Wordpress not destroy your server" cache.

Re: Researching a new form of HTTP caching optimization

#45

I think it's been said enough here but Varnish can certainly do almost everything that they are saying it can't do, including some other storage optimizations like storing the gzipped response and serving a non-gzipped when requested (as of Varnish 3.0). You can use Vary for tons of caching optimizations via varnish, such as caching mobile web-pages vs non-mobile web pages or just a particular header. It's all about…

You're reading too much hostility in it. The article does not claim to be better than Varnish. Performance is achieved by not implementing many features. For example, Varnish is a full-blown programming language and has an infinite size. The Passenger turbocache has almost no configuration options, does not support any sort of custom programming and only supports 8 entries at most. The fact that the max size is so sm…

I think the complaint is just that the approach is in no way as novel as you make it seem.

It can and has been implemented with Varnish and a few lines of VCL (with support of the app as well, of course).

What is "pure varnish" anyways? Proper varnish use always needs a tuned VCL, that's the whole core of the product.

Also, if I might say, I find your edits very handwavey. Please prove why that is impossible in VCL.

Re: Researching a new form of HTTP caching optimization

#46
post #45

Earlier quoted context omitted.

You're reading too much hostility in it. The article does not claim to be better than Varnish. Performance is achieved by not implementing many features. For example, Varnish is a full-blown programming language and has an infinite size. The Passenger turbocache has almost no configuration options, does not support any sort of custom programming and only supports 8 entries at most. The fact that the max size is so sm…

I think the complaint is just that the approach is in no way as novel as you make it seem. It can and has been implemented with Varnish and a few lines of VCL (with support of the app as well, of course). What is "pure varnish" anyways? Proper varnish use always needs a tuned VCL, that's the whole core of the product. Also, if I might say, I find your edits very handwavey. Please prove why that is impossible in VCL.

Fair enough. But even claiming that it's truly novel is not the point of the article. The point of the article is to research HTTP caching and to converse with the community about possibilities. It is not to present a new product.

In hindsight I see that the title may have been badly chosen. Before publication, none of the test readers have made any fuss about this.

> Please prove why that is impossible in VCL.

Where do you get impression that I claimed it's impossible in the VCL? It's pretty clear that the single page app approach can be replaced by edge side include, while the cookie parsing can be done with the cookie vmod.

The article claims that despite being the cache being able to do these things, application support is still required. The app has to be modified to output certain cookies in a certain format, e.g. the vary-on-user-permission-level thing. It's the combination that is important.

Have these things been done before? I'm sure they have. Most ideas in computer science are 30+ years old, and it's rare to truly find something new. But again, the point of the article is research. What we're after is not to present a new thing, but to present an idea, and if it's a new thing then we want people to help us to test; if it's not a new thing then we want to hear experiences.

Re: Researching a new form of HTTP caching optimization

#47

Sorry to barge on this thread - but does have a reasonable varnish config that works for a wordpress site behind https nginx and W3 Total Cache ? It seems strangely hard to configure something like this.

I used (and modified) one based on Dreamhost's https://github.com/dreamhost/varnish-vcl-collection/blob/mas... but there's a bunch of others on Github if you search for them. Note that this isn't a shortcut so you don't have to learn VCL... and that the way I did it was to put Varnish on port 80 and the web server on another port. I've seen other configs where a load balancer asks Varnish when it knows varnish should…

thanks for this !

I guess you dont have an SSL termination point in front. What I was thinking of was nginx -> varnish -> nginx.

Re: Researching a new form of HTTP caching optimization

#48

Earlier quoted context omitted.

I used (and modified) one based on Dreamhost's https://github.com/dreamhost/varnish-vcl-collection/blob/mas... but there's a bunch of others on Github if you search for them. Note that this isn't a shortcut so you don't have to learn VCL... and that the way I did it was to put Varnish on port 80 and the web server on another port. I've seen other configs where a load balancer asks Varnish when it knows varnish should…

thanks for this ! I guess you dont have an SSL termination point in front. What I was thinking of was nginx -> varnish -> nginx.

Ah, actually we do, but that runs on the load balancer. We currently use nginx on the LB but you could use haproxy alone these days.

Re: Researching a new form of HTTP caching optimization

#49

Earlier quoted context omitted.

thanks for this ! I guess you dont have an SSL termination point in front. What I was thinking of was nginx -> varnish -> nginx.

Ah, actually we do, but that runs on the load balancer. We currently use nginx on the LB but you could use haproxy alone these days.

When you use nginx as ssl termination loadbalancer - do you just do a proxy forward to varnish, or is it anything complicated ?
Post reply on HN