[squid-users] Queue incoming requests when fetching from origin

Jaap Dam jaap.dam at gmail.com
Mon Jun 20 09:43:27 UTC 2016


Hi Eliezer,

Yes, Jaap is my first name :)
I might have not mentioned this before, but I'm using Squid as a reverse
proxy / in acceleration mode. So as far as I know your comments are not
applicable. Thanks for your thoughts though!

Jaap

2016-06-19 7:16 GMT+02:00 Eliezer Croitoru <eliezer at ngtech.co.il>:

> Hey Jaap, (not sure if it's the first name)
>
> The issue is that there are consequences for cached objects not being
> revalidated.
> Also if there are sites which needs to be targeted it would be a different
> story.
> Some might not understand the difference between a cache and an archive or
> want it to act as one.
> A cache is meant to be temporary while archive should last longer.
> One example is Windows Updates which might needs to be archived since it's
> always needed.
>
> If you have a specific targeted site, let me know and I will try to see if
> something can be done.
>
> Eliezer
>
> ----
> Eliezer Croitoru
> Linux System Administrator
> Mobile: +972-5-28704261
> Email: eliezer at ngtech.co.il
>
>
> -----Original Message-----
> From: squid-users [mailto:squid-users-bounces at lists.squid-cache.org] On
> Behalf Of Alex Rousskov
> Sent: Friday, June 17, 2016 6:22 PM
> To: Jaap Dam
> Cc: squid-users at lists.squid-cache.org
> Subject: Re: [squid-users] Queue incoming requests when fetching from
> origin
>
> On 06/17/2016 05:33 AM, Jaap Dam wrote:
>
> > From what I
> > understand, re-validation is useful when done with If-Modified-Since
> > or If-None-Match.
>
> To revalidate stale objects, Squid uses conditional requests. That is not
> the only way to revalidate, but that is what Squid does.
>
>
> > However my responses do not provide the E-Tag header nor the
> > Last-Modified header.
>
> IIRC, the If-Modified-Since field in a conditional request may use the
> response Date header when Last-Modified is not available. If the origin
> server supports checking resource modification times (without disclosing
> them in responses for some reason), revalidation would still work as
> intended.
>
>
> > Is it possible for Squid to never revalidate but always to assume
> > 'pure cache-miss' when a resource is stale?
>
> I am not sure. Others may be able to answer this question authoritatively.
> If you force me to guess, I would say "no".
>
> Alex.
>
>
>
> > 2016-06-16 17:20 GMT+02:00 Alex Rousskov
> > <rousskov at measurement-factory.com
> > <mailto:rousskov at measurement-factory.com>>:
> >
> >     On 06/16/2016 01:45 AM, Jaap Dam wrote:
> >
> >     > Thanks for the information. Could you elaborate on when collapsed
> >     > forwarding does apply?
> >
> >     Squid is currently able to collapse HTTP client [miss] requests (but
> not
> >     internally generated HTTP requests triggered by HTTP client
> requests).
> >     Furthermore, to be collapsable, the request must have no markings
> that
> >     make the future response uncachable.
> >
> >
> >     > With your extra information, my assumption would
> >     > be that it only applies on requests of a resource that has never
> been
> >     > cached before.
> >
> >     I would not phrase it like that because Squid does not remember was
> has
> >     been cached before, only what is still cached at the query time.
> There
> >     are three primary cases for an HTTP client request to consider here:
> >
> >     * pure cache hit: Collapsing is inapplicable because Squid does not
> send
> >     any requests (there is nothing to collapse). Each HTTP client
> request is
> >     satisfied from the Squid cache.
> >
> >     * pure cache miss: Multiple requests for the same missing object can
> be
> >     collapsed if collapsed_forwarding is enabled. Collapsable requests
> have
> >     no markings that make the future response uncachable.
> >
> >     * revalidation: The requested object was found in the cache but it
> was
> >     stale. Squid sends an internal "revalidation" request to the origin
> >     server or peer. These internal requests are currently not collapsed.
> We
> >     are working on collapsing them as well.
> >
> >
> >     > Secondly would you have a suggestion for solving the issue I'm
> facing?
> >
> >
> >     I have not studied the issue you are facing, but if you think
> collapsing
> >     revalidation requests would solve your problem, then either wait for
> us
> >     to finish initial collapsed revalidation support (and then see if it
> >     solves your problem) or co-sponsor that ongoing development (to make
> >     sure it solves your problem).
> >
> >
> >     HTH,
> >
> >     Alex.
> >
> >
> >
> >     > 2016-06-15 17:19 GMT+02:00 Alex Rousskov:
> >     >
> >     >     On 06/14/2016 02:51 AM, Jaap Dam wrote:
> >     >
> >     >     > I've part of the logging as an attachment. I'm requesting a
> >     single URL
> >     >     > in this log. The log starts with a stale cache of the item.
> >     >
> >     >     Collapsed forwarding does not apply to cache revalidation
> >     requests yet.
> >     >     Factory is working on implementing collapsed revalidations (in
> >     some
> >     >     environments), but I cannot promise a specific delivery date
> >     or that
> >     >     your particular environment will be covered.
> >     >
> >     >     Alex.
> >     >
> >     >
> >     >
> >     >
> >     >     > 2016-06-13 15:34 GMT+02:00 Amos Jeffries:
> >     >     >
> >     >     >     On 14/06/2016 12:29 a.m., Jaap Dam wrote:
> >     >     >     > Is the collapsed_forwarding directive the correct one
> >     to use
> >     >     for my
> >     >     >     > use-case or am i missing something?
> >     >     >
> >     >     >     Yes it is correct so far as I am understanding your need.
> >     >     >
> >     >     >     For further debugging about what is going on you will
> >     need the
> >     >     HTTP
> >     >     >     messages involved. Add the directive "debug_options 11,2
> >     20,3"
> >     >     to your
> >     >     >     config to get them logged in cache.log.
> >     >
> >     >
> >
> >
>
> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20160620/9094556e/attachment.html>


More information about the squid-users mailing list