<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>
    In a nutshell - I need no possible explanation. I want to know -
    it's a bug or so conceived?<br>
    <br>
    26.10.15 1:17, Eliezer Croitoru пишет:<br>
    <span style="white-space: pre;">> Hey Yuri,<br>
      ><br>
      > I am not sure if you think that Squid version 4 with extreme
      low hit ratio is bad or not but I can understand your sight about
      things.<br>
      > Usually I am redirecting to this page:
<a class="moz-txt-link-freetext" href="http://wiki.squid-cache.org/Features/StoreID/CollisionRisks#Several_real_world_examples">http://wiki.squid-cache.org/Features/StoreID/CollisionRisks#Several_real_world_examples</a><br>
      ><br>
      > But this time I can proudly say that the squid project is
      doing things the right way while it might not be understood by
      some.<br>
      > Before you or anyone declares that there is a low hit ratio
      due to something that is missing I will try to put some sense into
      how things looks in the real world.<br>
      > Small thing from a nice day of mine:<br>
      > I was sitting talking with a friend of mine, a MD to be exact
      and while we were talking I was just comforting him about the
      wonders of Computers.<br>
      > He was complaining on how the software in the office moves so
      slow and he needs to wait for the software to response with
      results. So I hesitated a bit but then I asked him "What would
      have happen if some MD here in the office will receive the wrong
      content\results on a patient from the software? he described it to
      me terrified from the question 'He can get the wrong decision!'
      and then I described to him how he is in such a good place when he
      doesn't need to fear from such scenarios.<br>
      > In this same office Squid is being used for many things and
      it's crucial that besides the option to cache content the
      possibility to validate cache properly will be set right.<br>
      ><br>
      > I do understand that there is a need for caches and sometimes
      it is crucial in order to give the application more CPU cycles or
      more RAM but sometimes the hunger for cache can consume the actual
      requirement for the content integrity and it must be re-validated
      from time to time.<br>
      ><br>
      > I have seen couple times how a cache in a DB or other levels
      results with a very bad and unwanted result while I do understand
      some of the complexity and caution that the programmers take when
      building all sort of systems with cache in them.<br>
      ><br>
      > If you do want to understand more about the subject pick your
      favorite scripting language and just try to implement a simple
      object caching.<br>
      > You would then see how complex the task can be and you can
      maybe then understand why caches are not such a simple thing and
      specially why ignore-no-cache should not be used in any
      environment if it is possible.<br>
      ><br>
      > While I do advise you to not use it I would hint you and
      others on another approach to the subject.<br>
      > If you are greedy and you have hunger for cache for specific
      sites\traffic and you would like to be able to benefit from
      over-caching there is a solution for that!<br>
      > - You can alter\hack squid code to meet your needs<br>
      > - You can write an ICAP service that will be able to alter
      the response headers so squid would think it is cachable by
      default.<br>
      > - You can write an ECAP module that will be able to alter the
      response headers ...<br>
      > - Write your own cache service with your algorithms in it.<br>
      ><br>
      > Take in account that the squid project tries to be as fault
      tolerance as possible due to it being a very sensitive piece of
      software in very big production systems.<br>
      > Squid doesn't try to meet the requirement of "Maximum Cache"
      and it is not squid that as a caching proxy makes a reduction of
      any cache percentage!<br>
      > The reason that the content is not cachable is due to all
      these application that describe their content as not cachable!<br>
      > For a second of sanity from the the squid project, try to
      contact google\youtube admins\support\operators\forces\what-ever
      to understand how would you be able to benefit from a local cache.<br>
      > If and when you do manage to contact them let them know I was
      looking for a contact and I never managed to find one of these
      available to me on the phone or email. You cannot say anything
      like that on the squid project, the squid project can be contacted
      using an email and if required you can get a hold of the man
      behind the software(while he is a human).<br>
      ><br>
      > And I will try to write it in a geeky way:<br>
      > deny_info 302:<a class="moz-txt-link-freetext" href="https://support.google.com/youtube/">https://support.google.com/youtube/</a>
      big_system_that_doesnt_want_to_be_cached<br>
      ><br>
      > Eliezer<br>
      ><br>
      > * P.S If you do want to write an ICAP service or an ECAP
      module to replace the "ignore-no-cache" I can give you some code
      that will might help you as a starter.<br>
      ><br>
      ><br>
      > On 25/10/2015 17:17, Yuri Voinov wrote:<br>
      >><br>
      > Hi gents,<br>
      ><br>
      > Pay attention to whether someone from the test SQUID 4 as
      extremely low<br>
      > of cache hits from the new version? Particularly with respect
      to sites<br>
      > HTTPS directive "no cache"? After replacing the Squid 3.4 to
      4 squid<br>
      > cache hit collapsed from 85 percent or more on the level of
      5-15<br>
      > percent. I believe this is due to the exclusion of support
      guidelines<br>
      > ignore-no-cache, which eliminates the possibility of
      aggressive caching<br>
      > and reduces the value of caching proxy to almost zero.<br>
      ><br>
      > This HTTP caches normally. However, due to the widespread use
      of HTTPS<br>
      > trends - caching dramatically decreased to unacceptable
      levels.<br>
      ><br>
      > Noticed there anyone else this effect? And what is now with
      caching?<br>
      ><br>
      >><br>
      >><br>
      >> _______________________________________________<br>
      >> squid-users mailing list<br>
      >> <a class="moz-txt-link-abbreviated" href="mailto:squid-users@lists.squid-cache.org">squid-users@lists.squid-cache.org</a><br>
      >> <a class="moz-txt-link-freetext" href="http://lists.squid-cache.org/listinfo/squid-users">http://lists.squid-cache.org/listinfo/squid-users</a><br>
      >><br>
      ><br>
      > _______________________________________________<br>
      > squid-users mailing list<br>
      > <a class="moz-txt-link-abbreviated" href="mailto:squid-users@lists.squid-cache.org">squid-users@lists.squid-cache.org</a><br>
      > <a class="moz-txt-link-freetext" href="http://lists.squid-cache.org/listinfo/squid-users">http://lists.squid-cache.org/listinfo/squid-users</a></span><br>
    <br>
    -----BEGIN PGP SIGNATURE-----
<br>
    Version: GnuPG v2
<br>
     <br>
    iQEcBAEBCAAGBQJWLS2oAAoJENNXIZxhPexGupAIAM4ss9lrXBloXAWpGlQXLH0A
<br>
    aoyPKYYd4qQ/MMhKH7TWGOQnU+qJsOY28x8/jVu2O2A6pwUPmRx6czf2TEK1hRB2
<br>
    e1hDSP2sU/CNUHEJ+r1tIuMIM8zIX7BX5rdqhDKdVFj25w9cNS2r3Hv9zRfL833A
<br>
    /CzVthnTWguykI3P8IEChoANV8Li8Uz6rDxi8X+MIQ0dEvFoVWnOiPamcbur7iBg
<br>
    lnKPAORuQ3C0Jch4AzfYxVaDuw+r9Snw93a6ZDISv4UsWbI8pBWvhcOE2X7M+akY
<br>
    Huuhi0FkuAla4dXN2mA5+Lu+4MBJ+z0yqtu/KQ2zgdF2znGDA1JPJwjYgCfIjOg=
<br>
    =OjYt
<br>
    -----END PGP SIGNATURE-----
<br>
    <br>
  </body>
</html>