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
[email protected]
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
_______________________________________________
varnish-dev mailing list
[email protected]
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
