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. _______________________________________________ squid-dev mailing list [email protected] http://lists.squid-cache.org/listinfo/squid-dev
