<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <br>
    -----BEGIN PGP SIGNED MESSAGE----- <br>
    Hash: SHA256 <br>
     <br>
    The answer is simple.<br>
    <br>
    Look ath this row from 3.5.10 access.log:<br>
    <br>
    1445879345.827     48 127.0.0.1 TCP_MEM_HIT/200 24425 GET
    <a class="moz-txt-link-freetext" href="https://upload.wikimedia.org/wikipedia/commons/thumb/8/8c/Teller-Ulam_device.png/200px-Teller-Ulam_device.png">https://upload.wikimedia.org/wikipedia/commons/thumb/8/8c/Teller-Ulam_device.png/200px-Teller-Ulam_device.png</a>
    - HIER_NONE/- image/png<br>
    <br>
    We can see a big enoug image from Wiki. Mem hit, yea?<br>
    <br>
    With next request we got TCP_HIT, when image comes from disk cache
    after swap out.<br>
    <br>
    Refresh pattern from 3.5.10 related to this URL:<br>
    <br>
    # Other long-lived items<br>
    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<br>
    <br>
    Then we look in 4.0.1 access.log with the same image:<br>
    <br>
    14458854979.432     48 127.0.0.1 TCP_MISS/200 24425 GET
    <a class="moz-txt-link-freetext" href="https://upload.wikimedia.org/wikipedia/commons/thumb/8/8c/Teller-Ulam_device.png/200px-Teller-Ulam_device.png">https://upload.wikimedia.org/wikipedia/commons/thumb/8/8c/Teller-Ulam_device.png/200px-Teller-Ulam_device.png</a>
    - HIER_NONE/- image/png<br>
    <br>
    # Other long-lived items<br>
    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<br>
    <br>
    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??????<br>
    <br>
    Both servers has the similar squid.conf. Both images are static.<br>
    <br>
    Well, now we goes to redbot.org and check this URL:<br>
    <br>
    <a class="moz-txt-link-freetext" href="http://i.imgur.com/KiydfT0.png">http://i.imgur.com/KiydfT0.png</a><br>
    <br>
    What we seen?<br>
    <br>
    <br>
          Caching<br>
    <br>
      * This response allows all caches to store it.<br>
      * This response cannot be served from cache without validation.<br>
    <br>
    So, what's wrong with Squid NOW?<br>
    <br>
    Interesting, isn't it?<br>
    <br>
    26.10.15 23:01, Alex Rousskov пишет:<br>
    <span style="white-space: pre;">> On 10/26/2015 04:41 AM, Yuri
      Voinov wrote:<br>
      ><br>
      >> what has changed so much that the same<br>
      >> configuration I get 10 times smaller cache hit.<br>
      ><br>
      > You are asking a good question. I do not think anybody knows
      the exact<br>
      > answer -- too many things have changed in general to either
      identify the<br>
      > changes that have affected your [complicated] setup or to
      exclude all of<br>
      > the changes and blame some yet-unknown v4 bug.<br>
      ><br>
      ><br>
      > However, the following procedure is almost guaranteed to lead
      you to the<br>
      > answer:<br>
      ><br>
      > 1. Find a URL/resource that was served from the cache in v3
      but became a<br>
      > miss in v4. You probably have access.logs that can be used
      for that. If<br>
      > not, enable them and run more experiments. Since your drop in
      hit ratio<br>
      > is so drastic, it should not take long to find a URL that was
      usually a<br>
      > hit before and is usually a miss now (or that becomes a
      hit/miss as soon<br>
      > as you switch to v3/4).<br>
      ><br>
      > 2. Reproduce the v4 miss with an ALL,9 cache.log and share
      that log. Do<br>
      > this using single-transaction command-line tools, with no
      other traffic<br>
      > going through Squid. Others on this list can guide you as to
      what<br>
      > logging options to use if you do not want to run with ALL,9.<br>
      ><br>
      > The above requires some work on your part. It is a good idea
      to run<br>
      > these tests in a non-production environment (which may
      require even more<br>
      > work from you). Needless to say, you are not required to do
      that extra<br>
      > work. However, some extra work is most likely required if you
      want to<br>
      > get the answer to your question because there is currently
      not enough<br>
      > information to answer it.<br>
      ><br>
      ><br>
      > HTH,<br>
      ><br>
      > Alex.<br>
      ></span><br>
    <br>
    -----BEGIN PGP SIGNATURE-----
<br>
    Version: GnuPG v2
<br>
     <br>
    iQEcBAEBCAAGBQJWLmC+AAoJENNXIZxhPexGGj8IAKfXg0FZU/27pZxcga0cmcRD
<br>
    lSKxRf9zwxpGu5lZ9ubDaZwf/SYlish8Ej7pQkzTSTi4ApVP5QWYg4P9DoY1PnJ2
<br>
    ziSwFPuc3zVmgm8ua8fKUL+zsBMe46xIBNHino13dEN4tzFgxm4gQ2VjDOk/0S2n
<br>
    xM0svah0UDBiagSeyKt7SeDIwZRNNhMywiALwyjltrYc73OkfrwLt4yDE08SehOi
<br>
    phDlsVwaaQDqOk8AauYoNl55BBa3Qj+GlqJ3CduIIU6C54+6cAYG8V3YTJtwFFvX
<br>
    wLa7u5PWB5fkWAiuS+ZlKdG3A2KRO16Ya87dMCdu0GaYTS0eo2I+sqtCiCCRgg8=
<br>
    =ahlV
<br>
    -----END PGP SIGNATURE-----
<br>
    <br>
  </body>
</html>