Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Researching a new form of HTTP caching optimization

blog.phusion.nl

Post reply on HN
Print view View original

21–30 of 50 posts

Re: Researching a new form of HTTP caching optimization

#21

Post by FooBarWidget »

WimLeers wrote: post #13

> What if the cache can parse cookies and vary the cached response by the value of a specific cookie, not the entire header? > This is caching that Varnish and other “normal” HTTP caches (including CloudFlare) could not have done. This is false. I'm not at all very familiar with Varnish, but I know this is easily possible, and has been used for many, many years. E.g. for Drupal + Varnish, i.e. to only keep Drupal's s…

The first example looks nothing like parsing a specific cookie. It merely sanitizes the cookie headers a little, but it doesn't extract out a specific cookie to use as cache key.

And both examples you link to remove cookies. That's not what we're after. We're after the extraction of a specific cookie without removing anything.

It's also not marketing for a commercial product. The research is for an open source project, and the code is public and open source. The entire point of the blog post is to call for research participants who could not only test our ideas, but who could also point out anything we might have missed.

Re: Researching a new form of HTTP caching optimization

#22

Post by megaman821 »

I almost always configure Varnish not to cache on Vary Cookie and pair that with some simple changes on the back-end to keep most my pages cacheable.

One, don't blindly set Vary Cookie on every single page. Two, when a page only needs minor variation like a username; store the username in a cookie and use JavaScript to display it on the page.

Re: Researching a new form of HTTP caching optimization

#24

Post by WimLeers »

FooBarWidget wrote: post #21
WimLeers wrote: post #13

> What if the cache can parse cookies and vary the cached response by the value of a specific cookie, not the entire header? > This is caching that Varnish and other “normal” HTTP caches (including CloudFlare) could not have done. This is false. I'm not at all very familiar with Varnish, but I know this is easily possible, and has been used for many, many years. E.g. for Drupal + Varnish, i.e. to only keep Drupal's s…

The first example looks nothing like parsing a specific cookie. It merely sanitizes the cookie headers a little, but it doesn't extract out a specific cookie to use as cache key. And both examples you link to remove cookies. That's not what we're after. We're after the extraction of a specific cookie without removing anything. It's also not marketing for a commercial product. The research is for an open source projec…

> The first example looks nothing like parsing a specific cookie. It merely sanitizes the cookie headers a little, but it doesn't extract out a specific cookie to use as cache key.

You say you don't parse a specific cookie, but doesn't extract a specific cookie as a cache key? The blog post says the opposite:

> We modified Passenger to parse cookies, and to vary turbocache responses based on the value of this user_id cookie. We invoke Passenger like this: passenger start --vary-turbocache-by-cookie user_id

In other words: parse the user_id cookie.

The mentioned commit even adds a ~250 LoC file (ext/common/ServerKit/CookieUtils.h) to do cookie parsing: https://github.com/phusion/passenger/commit/a760649cd79fde43...

---

Anyway, what you're getting at is that Phusion only parses a certain value from the cookie and then uses it as a custom Vary header, whereas the examples I linked to clean up the Cookie header and then varies on that cleaned up Cookie header. That boils down to exactly the same thing.

P.S.: downvoting? Not very nice.

Re: Researching a new form of HTTP caching optimization

#25

Post by cordite »

chris_overseas wrote: post #8

I had a contract at a company about 13 years ago where I was working on a web-based CMS that had been built entirely in-house. Because each rendered page's content was built up in a hierarchical manner, I added a caching layer that allowed arbitrary portions of the rendered page "tree" to be cached all the way up to the entire page and HTTP response if possible. Each cached portion could be located quickly based on i…

I believe Stack Overflow does some of this too. Though I can't seem to find the source that convinced me of such.

Re: Researching a new form of HTTP caching optimization

#26

Post by chris_overseas »

jacquesm wrote: post #9
chris_overseas wrote: post #8

I had a contract at a company about 13 years ago where I was working on a web-based CMS that had been built entirely in-house. Because each rendered page's content was built up in a hierarchical manner, I added a caching layer that allowed arbitrary portions of the rendered page "tree" to be cached all the way up to the entire page and HTTP response if possible. Each cached portion could be located quickly based on i…

Most major frameworks include something like this but it's usually harder to use, 'partials' caching as it is called is a pretty effective way to speed up the server side of things when you need that. Varnish has a similar facility (which allows you to abstract it out of the framework code entirely). A dependencies ('make') like automatic approach to this would be quite nice to have, maybe your approach could be retr…

Thanks, I hadn't heard of the names "Russian doll" or "partials" before. I haven't worked with a CMS (or even web apps at all really) for over a decade now but I'm surprised you seem to imply that automatic dependency management isn't standard stuff these days already. It was certainly very useful to us, though admittedly tricky to implement robustly.

Re: Researching a new form of HTTP caching optimization

#27

Post by FooBarWidget »

WimLeers wrote: post #24
FooBarWidget wrote: post #21

Earlier quoted context omitted.

The first example looks nothing like parsing a specific cookie. It merely sanitizes the cookie headers a little, but it doesn't extract out a specific cookie to use as cache key. And both examples you link to remove cookies. That's not what we're after. We're after the extraction of a specific cookie without removing anything. It's also not marketing for a commercial product. The research is for an open source projec…

> The first example looks nothing like parsing a specific cookie. It merely sanitizes the cookie headers a little, but it doesn't extract out a specific cookie to use as cache key. You say you don't parse a specific cookie, but doesn't extract a specific cookie as a cache key? The blog post says the opposite: > We modified Passenger to parse cookies, and to vary turbocache responses based on the value of this user_id…

I am from Phusion. No idea who downmodded you, but this happens often on HN.

But what you mentioned is not the same thing. In the examples you linked to, Google Analytics and other cookies are removed, leaving only a single cookie. But that's not what we're after. We want to vary by a specific cookie, without removing the other cookies.

For example, Rails stores the session data in a session cookie. We advocate introducing a user_id cookie in addition to the session cookie. Using your approach, the session data would be removed, which breaks the application. Our approach leaves all original cookie data intact while still varying on a specific cookie.

Furthermore, another idea that we've described in the blog post is to vary based some user property, e.g. the user's permission level, in order to increase the cardinality of cache entries. This is not something you can do with only Varnish: it requires cooperation from the app.

Re: Researching a new form of HTTP caching optimization

#28

Post by codingjester »

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 just flexing a little bit of VCL (which I'll admit sometimes can throw people off).

They had me until this part:

> This is an HTTP cache built directly in Passenger so that it can achieve much higher performance than external HTTP caches like Varnish.

And since they have no benchmarks to really back up these claims, I'm skeptical they did much research against Varnish to tune or set it up. I'd love to see the numbers on varnish vs their turbocache. Without numbers, I have to take a lot of it with a grain of salt.

Either way, seems like it could be an extra handy thing to have in your toolbox, as long as it fits your stack.

Re: Researching a new form of HTTP caching optimization

#29

Post by FooBarWidget »

codingjester wrote: post #28

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 small allows it to be implemented in very compact data structures, but its usefulness is also severely limited. It's merely designed with a different set of tradeoffs than Varnish.

It isn't that difficult to make a web server that's faster all the production servers out there. For example H2O is faster than Nginx... because it has infinitely less features. Ditto for Passenger's turbocache.

The rest of the article describes some ideas, some of which cannot be implemented using pure Varnish and require cooperation from the app. In my opinion you're missing out on a lot of interesting ideas if you stop reading only because you think Varnish is being slammed.

Re: Researching a new form of HTTP caching optimization

#30

Post by codingjester »

FooBarWidget wrote: post #29
codingjester wrote: post #28

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…

Fair enough! I can definitely see how I might have taken it too hard (or it came off in my writing of the comment)

I was just more or less intrigued by the actual claim and would have loved to just see some numbers on "higher performance than varnish" and the scenarios where it could reach those performance pieces. It just piqued my interest for future architecture considerations.

Thanks for enlightening me more on turbocache. It's on my list of things to go through tonight.

Edit: I did want to point out my bad choice of words. "They had me until here.", did not mean I didn't read the article in it's entirety. Just that I continued with a bit more skepticism.

Post reply on HN