[squid-dev] [PATCH] Collapse internal revalidation requests (SMP-unaware caches)

[Alex Rousskov]

On 07/20/2016 07:21 AM, Amos Jeffries wrote:
> Probably more a question for Alex;
>   whats the point of UsingSmp() in determining transients
> initialization? I would expect collapsing to be doable in both SMP and
> non-SMP modes.

You are correct: Basic collapsed forwarding works in both SMP and
non-SMP modes, but Transients are not _needed_ for non-SMP mode and may
actually be harmful there. Here is a summary, for the record:

* Caching is supported in both modes.

* Basic collapsed forwarding is supported in both modes.
* Collapsed revalidation is supported in non-SMP mode only [for now?].

* Transients are needed for SMP caching to work.
  Transients are not needed for and are harmful in non-SMP mode.
  They are no longer created when not needed, fixing at least bug 4311.

* Configurations mixing SMP-aware and non-SMP-aware caches
  in SMP mode are still not supported.


> In related things. I am working on improving the log tags to report to
> which transactions have been delayed by collapsed forwarding. ie. the
> crSlave transactions in this patch.

Please note that being collapsed (crSlave) does not imply a delay. If
collapsing was a success (i.e., the slave was able to use the response
received by an "earlier" concurrent transaction), then it actually
implies a [small] speedup! If collapsed forwarding was a failure (i.e.,
the response was not cachable/usable), then there will likely be a delay
indeed.

If crSlave transactions are "tagged", then an access log reader may be
able to tell whether they were successful by examining [the lack of]
some origin server connection details, but I have not tested that theory.

I agree that it would be useful to "tag" crSlave transactions in access
logs somehow, but I have not studied the best approach to doing so IIRC.


Thank you,

Alex.