<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jul 28, 2015 at 12:54 PM, Amos Jeffries <span dir="ltr"><<a href="mailto:squid3@treenet.co.nz" target="_blank">squid3@treenet.co.nz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 29/07/2015 5:53 a.m., Tory M Blue wrote:<br><br>
<br>
> I just reproduced this by hand, using an HTTP sniffer tool. I requested<br>
> the same URL twice, with about a 0.25 second delay between fetches, and the<br>
> 2nd attempt was ALSO A MISS. Then I waited 1 second and tried a 3rd time,<br>
> and it was FINALLY a hit.<br>
<br>
Had the first request finished being delivered to your testing tool<br>
before the second request was sent?<br></blockquote><div><br></div><div><br></div><div>Yes our testing is completely sequential meaning the connection has to complete before we launch another, even by hand.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> Squid v3 seems to have changed the way it stores objects. Maybe it is<br>
> doing some sort of "asynchronous" background store now, so if you send in<br>
> sequential requests without a delay between, it may not actually have<br>
> finished storing it yet, so it doesn't report a "hit". Meaning, the first<br>
> "miss" response may have fired off a thread to store the object, and not<br>
> doing it in the main thread anymore like in v2, if you get my meaning.<br>
<br>
Squid-3 in-transit objects are not listed as existing in cache_mem<br>
storage until they have completely (and successfully) finished their<br>
first use.<br>
<br>
<br>
You can configure "collapsed_forwarding on" to enable the Squid-2.7<br>
behaviour. Treating the in-transit objects list as if it were another<br>
cache area.<br>
<br><br></blockquote><div>The document cite this is quite a bit different and not something I want to embark upon. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
><br><br>
<br>
Timing between *completion* of the first request and starting of the<br>
second is the critical. If the first request has not finished, theres no<br>
hope of a HIT.<br>
<br>
Also size of memory cache relative to the churn currently going on also<br>
matters. If you wait too long between the test requests it will be<br>
pushed out and get a MISS again anyway. But I dont think that is a<br>
factor with 250ms being your timing.<br></blockquote><div><br></div><div><br></div><div>Again completely synchronous, something is not happening as it should under a busy condition, we tested this as far out as 5 seconds and still got a miss. We have added "5" retries to our monitor, but I do think something is a miss (no pun intended). Single client hitting a single server in a synchronous manner, should allow for a pretty quick cache hit, but it's not. </div><div><br></div><div>my high/low water marks are so</div><div><br></div><div>cache_swap_high 90<br></div><div>
<p class="p1"><span class="s1">cache_swap_low 80</span></p><p class="p1"><span class="s1"><br></span></p><p class="p1"><span class="s1">My space available is so</span></p><p class="p1"><span class="s1">
</span></p><p class="p1"><span class="s1">Filesystem Size Used Avail Use% Mounted on</span></p><p class="p1"><span class="s1">
</span></p><p class="p1"><span class="s1">/dev/ram0 17G 14G 2.3G 86% /cache01</span></p><p class="p1"><span class="s1">Any other data I could grab from the stats that would help. I do believe something is not quite right but we have ways to get around it for now,</span></p><p class="p1"><span class="s1"><br></span></p><p class="p1"><span class="s1">Thanks Amons</span></p><p class="p1"><span class="s1">Tory</span></p></div><div><br></div></div></div></div>