Hello Pinakee,
Look at the varnishlog, possibly using the "-d" switch and find your
request. If your request is a Hit-for-Pass, you should be able to see
"HIT-FOR-PASS" in it, or at the least see something like:
- VCL_return hash
- VCL_call HASH
*- VCL_return lookup*
- Debug "XXXX HIT-FOR-PASS"
- HitPass 3
*- VCL_call PASS*
Meaning we said "let's find the object!" but instead of returning a HIT,
varnish converted it into a PASS (hence the Hit-for-Pass name!).
That happens because someone in vcl_backend_response set the
beresp.uncacheable to true in the original request. So, one way could be to
turn back the hands of time and scour the varnishlog to find that original
request. But chances are that we won't have to. The logic that set
beresp.uncacheable to true in the original request will probably do the
same thing in the present one, so find the corresponding bereq, it's easy,
just find a line looking like:
- Link bereq *32774* pass
The bold number is the id of the request, go find it! If you are lazy, you
can also use "-g request" to group reqs with their bereq. Combine that with
"-q" and life is grand: varnishlog -d -q 'ReqURL ~ "/MY_URL_THAT_IS_PASSED"
' -g request
Now that we have the bereq, look at it closely, notably, look at the
cache-control header, and at the set-cookie one. Also, look at the TTL that
varnish set for this object by looking at the metadata. This is found in
the TTL line, the one starting with "RFC":
-- TTL RFC *-1 10 -1* 1508934970 1508934970 1508934957 0 0
In my case, ttl is -1, grace is 10, keep is -1.
Let's keep in mind, but also digress. Varnish has a little secret: when you
compile you vcl before using it, it appends its own built inversion of it
and if one of your function doesn't return (or simply doesn't exist), the
built-in version is run after your code. You can find the buitin.vcl in
"/usr/share/..." but also by running "varnishd -x builtin". And it's also
accessible here:
https://github.com/varnishcache/varnish-cache/blob/4.1/bin/varnishd/builtin.vcl Look at its version of vcl_backend_response: if ttl is zero or less, if
there's a set-cookie header, or if we don't like the cache-control (mainly
because it tell us that it's not cacheable), we set beresp.uncacheable and
store that info for 2 minutes. So chances are that your response triggered
that code.
Solutions include fixing your backend, using the vcl to fix the response,
or just returning(deliver) or return(abandon) in the vcl_backend_response
to prevent that code from being run.
Sooooooooooooooooo, was that all clear?
--
Guillaume Quintard
On Tue, Oct 24, 2017 at 8:05 AM, Pinakee BIswas <pinakee@waltzz.com> wrote:
> Hi,
>
> We are using Varnish 4.1.8 for our ecommerce site. We are getting lots of
> hit-for-pass. I have read bunch of articles on hit-for-pass and there seem
> to be issues with the same (like when cacheable pages are not getting
> cached).
>
> Would appreciate if you could throw some light on hit-for-pass:
>
> 1. how to figure out which URLs are cacheable but aren't getting
> cached due to hit-for-pass
> 2. how to fix 1? One approach given in the articles is reducing the
> TTL for hit-for-pass.
>
> Thanks,
>
> Pinakee
>
> _______________________________________________
> varnish-misc mailing list
> varnish-misc@varnish-cache.org
> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
>