Cookbook: HTTP Cache.. Varnish seems to not support etag headers

[awdng]

The cookbook states the following on Cache Invalidation
You should never need to invalidate cached data because invalidation is already taken into account natively in the HTTP cache models. If you use validation, you never need to invalidate anything by definition; and if you use expiration and need to invalidate a resource, it means that you set the expires date too far away in the future.

It recommends to use eTags/Last Modified headers instead. I could not get that to work with varnish and stumbled on this forum message: https://www.varnish-cache.org/forum/topic/2794

Also the FOSHttpCacheBundle seems to be built completely around Cache invalidation, there is not a word about Cache Validation using etags/last modified headers in their docs at http://foshttpcachebundle.readthedocs.org/en/latest/

So, i am mildly confused by this and what the recommended/best practice is and if the docs need to reflect that.

[stof]

@awdng FOSHttpCacheBundle is not built entirely around Cache invalidation. But one of its main feature is indeed the cache invalidation, because it is precisely meant to cover this use case. Cache valdiation is not covered in the FOSHttpCacheBundle doc, because there is no need of the bundle to use cache validation. The features available in Symfony are enough. The bundle is here to allow using cache expiration (with long dates) and cache invalidation rather than cache validation to achieve greater performance. but this is much more complex (it is very easy to forget to invalidate something).

Note that when using cache validation, you will often combine it with expiration too: using expiration for a few seconds/minutes/hours (depending on the timeframe in whihc you consider serving the old content is fine), and validation to avoid redoing all the backend work but only part of it when the cache expires if there has been no change.

[awdng]

@stof Thanks a lot. That explanation finally makes it clear to me. I was under the impression that varnish would actually do a request with the eTag on every request to check whether it should deliver the cached version or not INSTEAD of using expiration. I now understand that if the request from varnish to the backend AFTER the content expired will return NOT Modified, then varnish will just reuse the old cached version. So the eTag is just something supplied through the request to enable the checking in symfony which should ideally be faster than recomputing the whole page. (Just writing that down so people after me might find this to clear up some confusion).

[jbouzekri]

Hi, sorry to jump back on this thread but I have the same "issue" than awdng about the cache validation model (Last-Modified or ETag) with varnish. I understand that the proxy cache will issue a request each time to the web server and waiting for a 304 response code without content or a 200 with content and deciding if he should returns his cache or the response (and caching it by the way).

When reading the documentation, It seems this way for me. This is a short excerpt :

The validation model addresses this issue. Under this model, the cache continues to store responses. The difference is that, for each request, the cache asks the application whether or not the cached response is still valid. If the cache is still valid, your application should return a 304 status code and no content. This tells the cache that it's ok to return the cached response.

As you said, we can play a little with expiration header to not wait for this 304 response and use an old cache for a time.

However like awdng, I could not make it works with varnish. Is there somebody who could confirm that this feature (cache validation) does not exist in varnish ? And if this is the case, is there another solution implementing the full HTTP cache specification for coupling with SF2 ? and finally, why does the official documentation recommends this architecture with varnish if this is not supported ?

Thanks in advance. I am going absolutely crazy trying to make this work.

[awdng]

Hi @jbouzekri
As far as i understood @stof and as it makes sense to me now is this:
Varnish (or any other reverse proxy for that matter) will NOT do a request to your webserver each time to check if it should deliver the cached version or not, as this would negate the whole point of the reverse proxy in skipping your backend entirely and drive up response times considerably.

What you can do with etags is a scenario like this:
Varnish get a request which it has not cached yet and asks your backend for it, the backend will return that response with cache expiration headers of lets say 60 seconds. Now if you are using etags, the next time varnish would call your backend again (eg. in this case 60 seconds) you could tell varnish (hopefully quickly) that nothing has changed by returning a 304 Not Modified and varnish will continue to use its cached version until the expire time is over again.
Now if you totally need to invalidate cache from the backend side you can still do that.

What i also found confusing was the fact that the docs say you would never have to worry about invalidation if validation is set up properly, but imo that depends on the content and you would need to use pretty short cache expire times.

As you are going down the same route as me, i ended up using the FosHttpCacheBundle (https://github.com/FriendsOfSymfony/FOSHttpCacheBundle) to invalidate certain routes when needed and skipped etags entirely for now. I use that with 24H of cache expiration time in varnish which works great for now. If i understand this correctly i could still improve this with etags to tell varnish content has not changed after 24H to speed up the reloading.

@stof correct me if im wrong.

[stof]

@awdng the ETag or Last-Modified will require a call to your backend to validate it (this is the validation model). But you can indeed make it lighter than a request doing all the work (you often don't need to build the whole page to know whether the page changed since the provided date).
And because you may want to improve performance more, you can combine the Expiration and Validation model:

• send both the SharedMaxAge directive with a value of 5 minutes and the Last-Modified header
• during the next 5 minutes, Varnish will not ask you again about the page
• after these 5 minutes, the cache will have expired, so it will ask you again, but the Last-Modified header will allow to see there was no change and send a 304 with a SharedMaxAge of 5 minutes (caching it again for another 5 minutes timeframe).

This means that you will not have to render the full page again until it changes. But when there is a change, it will be visible to customers at most 5 minutes after the change (the worst case being when Varnish cached the request for 5 minutes just 1 second before you saved your change).
You get the best of both world: full cache hit for a short time (not reaching Symfony at all), but pages are updated when there is a change (and the 5 minutes timeframe can indeed be changed depending on your business requirements).

Cache invalidation is more complex (which is why the implementation is not in core but in FOSHttpCacheBundle). This involves using expiration with long timeframes (only in the Varnish shared cache, keeping short timeframes in browser cache as you cannot invalidate it), and then telling Varnish to invalidate its cache when you update a resource. This means that when updating a resource, you need to be able to identify all pages on which it is used to invalidate them all.

What i also found confusing was the fact that the docs say you would never have to worry about invalidation if validation is set up properly, but imo that depends on the content and you would need to use pretty short cache expire times.

If you use cache validation, when the content change, you will generate a different Last-Modified or ETag header (depending on what you use), thus making the previous cache expire without having to handle invalidating the cache for the pages rendering the content at the time you save the content.
Of course, determining the Last-Modified date might be complex depending of your content (but the same is true when using cache invalidation with FOSHttpCacheBundle, you still need to know all contents involved in the rendering of the page).
The validation model is not about using long cache expiration times (the expiration time is the time you allow before revalidating the cache on the backend, not the time for which Varnish will use the page it has in its cache).

[awdng]

@stof yes, my main point was that you can not use the Validation model without expiration. Or to say it differently: Varnish will only issue a request to check for 304 after the expiration time (which should be low when using the Validation model) has run out.

As the varnish dude is saying

You want to invalidate content in cache, not revalidate for every request. ```

So Validation is about combining it with the right expiration time and then optimizing for returning a 304 as fast as possible if the content indeed has not changed. Is that correct?

[stof]

@awdng well, you can pass an expiration time of 0 when using the validation model if the business does not allow you to serve a stale content even during a few seconds. But you will indeed not benefit from the Varnish performance fully as you will always reach the backend. (I would consider that the business requirements are a mistake in such case by preventing scaling and would then first try to make the business accept a change though).
And you should indeed return the 304 as fast as you can (generating the ETag as the sha1 of the content rendered by your template is an easy strategy, but not an efficient one as it requires doing everything)

Switching to invalidation as suggested by the Varnish dude is indeed a way to achieve better perf than with expiration+validation, as you will be able to use longer expiration time, but it is also much more complex: you need to identify what you must be invalidated, otherwise you will serve stale content for weeks or months. and FOSHttpCacheBundle is precisely about allowing to perform such task in an easier way (by taking care of part of the job)

[awdng]

@stof But would varnish cache at all if you are using an expiration time of 0, won't it just route the response through directly or is there a trick to let it keep the cache ? Or maybe Varnish uses its default ttl when no caching headers are returned by the backend ? Good to know that validation could be used alone in that case (with limited benefit).

I was thinking about a simple redis list that keeps records of which content has changed and then just asking that based on the etag and returning immediatly, but that would also add more complexity to the whole setup so i found using FOSHttpCacheBundle for invalidation to be easier in our case (content heavy website that rarely changes, saving a change of the content in the backend triggers an invalidation request of the resource and connected resources).

[ddeboer]

@awdng @jbouzekri Does this chapter in the FOSHttpCache library docs help?

[stof]

@awdng I think it would still cache the content (but I'm not an expert in Varnish configuration). When the backend returns a 304, it does not send the content again (which can save a lot of backend work by not generating it).
but validation alone is indeed of limited benefit

[jbouzekri]

Thank you very much for your answers. It clears a lot of things for me on the architecture side.

I totally agree with you @stof. If the customer cannot accept an expiration cache of some seconds before validating the cache state, there is surely a problem in the business definition.

@ddeboer the best solution for clearing stale cache is indeed cache invalidation with requests issued from the backend directly to the proxy (thanks guys from FOS for this awesome bundle :).

So if I summarize all this talk.

1. Varnish does not issue request to check the state of its cache in the validation strategy (it has not been implemented and this is a choice made by their creators. As they said. Quote : "The whole point of Varnish is to serve content without asking the backend")
2. The solution we talked about is to use both expiration and validation strategy. The expiration with a low ttl will put the cache in varnish on the first request and in another request when this cache expires, the validation workflow will launch and the backend can respond with an empty response 304 or a 200 with a content updated.
3. Use the second point but with a ttl of 0 to implement a kind of full validation strategy (it needs a POC to validate that varnish can cache the first response even with an expire of 0)

At the start, I reopened this post because we are currently doing this kind of POC in my company so I will post soon my conclusions for point 2 and 3 (tomorrow if I succeeded in configuring varnish).

@stof you opened FriendsOfSymfony/FOSHttpCacheBundle#141. But for me the FOS documentation is perfect and very easy to understand. I still think the problem is in the symfony documentation where it is said that you can replace the AppCache kernel wrapper by an externel proxy cache. However we just demonstrated that varnish does not work the same way (in validation strategy).

[stof]

@jbouzekri the FOSHttpCache library has the awesome doc. the issue I opened is still true as it is on the bundle repo (but the fix will be easy) 😄

[dbu]

yeah that is the complexity of having a component and a bundle separately. we don't want to duplicate the component doc into the bundle doc, but this means that the bundle doc is kind of "incomplete" - will look into better interlinking.

for the discussion of validation vs invalidation: there is one use case that does make sense to me in general: when a user modifies things in the frontend like commenting or such, he needs to see the change immediately, or he will think his comment got lost.