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@xxxxxxxxxxxxxxxxxxxxxxx>:
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@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
