[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