<div dir="ltr">Hello Pinakee,<div><br></div><div>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:</div><div><br></div><div><div>- VCL_return hash</div><div>- VCL_call HASH</div><div><b>- VCL_return lookup</b></div></div><div><div>- Debug "XXXX HIT-FOR-PASS"</div><div>- HitPass 3</div><div><b>- VCL_call PASS</b></div></div><div><br></div><div>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!).</div><div><br></div><div>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:</div><div><br></div><div>- Link bereq <b>32774</b> pass<br></div><div><br></div><div>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</div><div><br></div><div>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":</div><div><br></div><div><div>-- TTL RFC <b>-1 10 -1</b> 1508934970 1508934970 1508934957 0 0</div></div><div><br></div><div>In my case, ttl is -1, grace is 10, keep is -1.</div><div><br></div><div>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: <a href="https://github.com/varnishcache/varnish-cache/blob/4.1/bin/varnishd/builtin.vcl">https://github.com/varnishcache/varnish-cache/blob/4.1/bin/varnishd/builtin.vcl</a></div><div><br></div><div>Look at its version of <span style="color:rgb(36,41,46);font-family:SFMono-Regular,Consolas,"Liberation Mono",Menlo,Courier,monospace;font-size:12px;white-space:pre">vcl_backend_response</span>: 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.</div><div><br></div><div>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.</div><div><br></div><div>Sooooooooooooooooo, was that all clear?</div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>-- <br></div>Guillaume Quintard<br></div></div></div>
<br><div class="gmail_quote">On Tue, Oct 24, 2017 at 8:05 AM, Pinakee BIswas <span dir="ltr"><<a href="mailto:pinakee@waltzz.com" target="_blank">pinakee@waltzz.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<p>Hi,</p>
<p>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).</p>
<p>Would appreciate if you could throw some light on hit-for-pass:</p>
<ol>
<li>how to figure out which URLs are cacheable but aren't getting
cached due to hit-for-pass</li>
<li>how to fix 1? One approach given in the articles is reducing
the TTL for hit-for-pass.</li>
</ol>
<p>Thanks,</p>
<p>Pinakee<br>
</p>
</div>
<br>______________________________<wbr>_________________<br>
varnish-misc mailing list<br>
<a href="mailto:varnish-misc@varnish-cache.org">varnish-misc@varnish-cache.org</a><br>
<a href="https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc" rel="noreferrer" target="_blank">https://www.varnish-cache.org/<wbr>lists/mailman/listinfo/<wbr>varnish-misc</a><br></blockquote></div><br></div>