[squid-users] Squid4 has extremely low hit ratio due to lacks of ignore-no-cache

[Yuri Voinov]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
 
The answer is simple.

Look ath this row from 3.5.10 access.log:

1445879345.827     48 127.0.0.1 TCP_MEM_HIT/200 24425 GET
https://upload.wikimedia.org/wikipedia/commons/thumb/8/8c/Teller-Ulam_device.png/200px-Teller-Ulam_device.png
- HIER_NONE/- image/png

We can see a big enoug image from Wiki. Mem hit, yea?

With next request we got TCP_HIT, when image comes from disk cache after
swap out.

Refresh pattern from 3.5.10 related to this URL:

# Other long-lived items
refresh_pattern -i
\.(jp(e?g|e|2)|gif|png|tiff?|bmp|ico|svg|webp|flv|f4f|mp4|ttf|eot|woff2?)(\?.*)?$   
14400    99%    518400     override-expire override-lastmod
reload-into-ims ignore-private ignore-no-store

Then we look in 4.0.1 access.log with the same image:

14458854979.432     48 127.0.0.1 TCP_MISS/200 24425 GET
https://upload.wikimedia.org/wikipedia/commons/thumb/8/8c/Teller-Ulam_device.png/200px-Teller-Ulam_device.png
- HIER_NONE/- image/png

# Other long-lived items
refresh_pattern -i
\.(jp(e?g|e|2)|gif|png|bmp|ico|svg|web(p|m)|flv|f4f|mp(3|4)|ttf|eot|woff2?))(\?.*)?$   
14400    100%    518400    override-expire override-lastmod
reload-into-ims ignore-private ignore-no-store

Did you see principal difference? Ah, yes. 4.0.1 has more than 4 times
bigger mem_cache, 1 Gb. 1st example 3.5.10 has only 256 Mbytes. This is
the reason of miss??????

Both servers has the similar squid.conf. Both images are static.

Well, now we goes to redbot.org and check this URL:

http://i.imgur.com/KiydfT0.png

What we seen?


      Caching

  * This response allows all caches to store it.
  * This response cannot be served from cache without validation.

So, what's wrong with Squid NOW?

Interesting, isn't it?

26.10.15 23:01, Alex Rousskov пишет:
> On 10/26/2015 04:41 AM, Yuri Voinov wrote:
>
>> what has changed so much that the same
>> configuration I get 10 times smaller cache hit.
>
> You are asking a good question. I do not think anybody knows the exact
> answer -- too many things have changed in general to either identify the
> changes that have affected your [complicated] setup or to exclude all of
> the changes and blame some yet-unknown v4 bug.
>
>
> However, the following procedure is almost guaranteed to lead you to the
> answer:
>
> 1. Find a URL/resource that was served from the cache in v3 but became a
> miss in v4. You probably have access.logs that can be used for that. If
> not, enable them and run more experiments. Since your drop in hit ratio
> is so drastic, it should not take long to find a URL that was usually a
> hit before and is usually a miss now (or that becomes a hit/miss as soon
> as you switch to v3/4).
>
> 2. Reproduce the v4 miss with an ALL,9 cache.log and share that log. Do
> this using single-transaction command-line tools, with no other traffic
> going through Squid. Others on this list can guide you as to what
> logging options to use if you do not want to run with ALL,9.
>
> The above requires some work on your part. It is a good idea to run
> these tests in a non-production environment (which may require even more
> work from you). Needless to say, you are not required to do that extra
> work. However, some extra work is most likely required if you want to
> get the answer to your question because there is currently not enough
> information to answer it.
>
>
> HTH,
>
> Alex.
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
 
iQEcBAEBCAAGBQJWLmC+AAoJENNXIZxhPexGGj8IAKfXg0FZU/27pZxcga0cmcRD
lSKxRf9zwxpGu5lZ9ubDaZwf/SYlish8Ej7pQkzTSTi4ApVP5QWYg4P9DoY1PnJ2
ziSwFPuc3zVmgm8ua8fKUL+zsBMe46xIBNHino13dEN4tzFgxm4gQ2VjDOk/0S2n
xM0svah0UDBiagSeyKt7SeDIwZRNNhMywiALwyjltrYc73OkfrwLt4yDE08SehOi
phDlsVwaaQDqOk8AauYoNl55BBa3Qj+GlqJ3CduIIU6C54+6cAYG8V3YTJtwFFvX
wLa7u5PWB5fkWAiuS+ZlKdG3A2KRO16Ya87dMCdu0GaYTS0eo2I+sqtCiCCRgg8=
=ahlV
-----END PGP SIGNATURE-----

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20151026/c6a69f44/attachment.html>