Hit-for-pass

[Guillaume Quintard]

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 at 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 at varnish-cache.org
> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-misc/attachments/20171025/9960393e/attachment.html>