This option controls whether Squid is allowed to merge multiple
potentially cachable requests for the same URI before Squid knows
whether the response is going to be cachable.
When enabled, instead of forwarding each concurrent request for
the same URL, Squid just sends the first of them. The other, so
called "collapsed" requests, wait for the response to the first
request and, if it happens to be cachable, use that response.
Here, "concurrent requests" means "received after the first
request headers were parsed and before the corresponding response
headers were parsed".
This feature is disabled by default: enabling collapsed
forwarding needlessly delays forwarding requests that look
cachable (when they are collapsed) but then need to be forwarded
individually anyway because they end up being for uncachable
content. However, in some cases, such as acceleration of highly
cachable content with periodic or grouped expiration times, the
gains from collapsing [large volumes of simultaneous refresh
requests] outweigh losses from such delays.
Squid collapses two kinds of requests: regular client requests
received on one of the listening ports and internal "cache
revalidation" requests which are triggered by those regular
requests hitting a stale cached object. Revalidation collapsing
is currently disabled for Squid instances containing SMP-aware
disk or memory caches and for Vary-controlled cached objects.
A response reused by the collapsed request is deemed fresh in that
request processing context -- Squid does not apply refresh_pattern and
internal freshness validation checks to collapsed transactions. Squid
does apply send_hit rules.