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

[Jaap Dam]

Hi Alex,

Thank you very much for your detailed explanation!

>From your explanation I would assume that my problem could be solved if the
re-validation would be treated as a pure miss. From what I understand,
re-validation is useful when done with If-Modified-Since or If-None-Match.
However my responses do not provide the E-Tag header nor the Last-Modified
header. Is it possible for Squid to never revalidate but always to assume
'pure cache-miss' when a resource is stale?

Best regards

2016-06-16 17:20 GMT+02:00 Alex Rousskov <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.
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20160617/fb296515/attachment-0001.html>