default hit_for_pass usage

[Rogier R. Mulhuijzen]

What we object to specifically was that hit_for_pass is returned when 
(beresp.ttl <= 0). Which is true not just for things like 401, but also 
500 and 503. My primary objection is the 503.

Like Andreas says, it possible to get a 500 or 503 on a page either due to 
load or some temporary error, where the next request could result in a 
perfectly cacheable page. But with the hit_for_pass in place, all workers 
blocking on that URL before then will just go through to the backend 
en-masse for the next two minutes. Especially with a 503, which most 
probably means the backend isn't coping very well due to load, and I'd 
hate to see an error like that cause even more load on a backend.

I think the default.vcl should be more conservative, and looking at all 
the status codes other than the ones deemed cacheable by default, I can 
only think of 401 and 403 as needing a hit_for_pass.

Cheers,

 	Rogier/DocWilco

On Tue, 23 Aug 2011, Andreas Plesner Jacobsen wrote:

> I was just going through the docs, updating examples to 3.0 syntax.
>
> I fell over something that bothered me:
>
> https://www.varnish-cache.org/docs/trunk/faq/general.html#troubleshooting
>
> Has a section on increasing hit_for_pass ttl. I discussed rewriting this
> section with DocWilco on irc, and we came to the conclusion that the current
> default vcl may not be completely sane. For example, it looks like a 500 will
> cause varnish to hit_for_pass for the next two minutes, even though the next
> request could result in a nice cacheable 200.
>
> Any ideas? Was this already considered when writing the default?
>
> -- 
> Andreas
>
> _______________________________________________
> varnish-dev mailing list
> varnish-dev at varnish-cache.org
> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
>