Page History

...

Once all this enabled, you have something that is very close, but not quite the same, as Squid's Collapsed Forwarding.

Open Read Retry Timeout

The open read retry configurations attempt to reduce the number of concurrent requests to the origin for a given object. While an object is being fetched from the origin server, subsequent requests would wait open_read_retry_time milliseconds before checking if the object can be served from cache. If the object is still being fetched, the subsequent requests will retry max_open_read_retries times. Thus, subsequent requests may wait a total of (max_open_read_retries x open_read_retry_time) milliseconds before establishing an origin connection of its own. For instance, if they are set to 5 and 10 respectively, connections will wait up to 50ms for a response to come back from origin from a previous request, until this request is allowed through.

These settings are inappropriate when objects are uncacheable. In those cases, requests for an object effectively become serialized. The subsequent requests would await at least open_read_retry_time milliseconds before being proxies to the origin.

Similarly, this setting should be used in conjunction with Read While Write for big (those that take longer than (max_open_read_retries x open_read_retry_time) milliseconds to transfer) cacheable objects. Without the read-while-write settings enabled, while the initial fetch is ongoing, not only would subsequent requests be delayed by the maximum time, but also, those requests would result in another request to the origin server.

third configuration option, which is really only suitable when you know everything is cacheable, are related how to deal with locking out cache access until the origin response has come back. Combined with read-while-write this would completely mimic the behavior of Squid's Collapsed Forwarding. The downside is that non-cacheable content would also be serialized, which can severely affect latency. Since ATS now supports setting these settings per-request or remap rule, you can configure this to be suitable for your setup much more easily.

...

CONFIG proxy.config.http.cache.max_open_read_retries INT -1 
CONFIG proxy.config.http.cache.open_read_retry_time INT 10

The default means that the feature is disabled, and every connection is allowed to go to origin instantly. When enabled, you will try max_open_read_retries times, each with a open_read_retry_time timeout. Lets say you set these to 5 and 10 respectively, connections will wait up to 50ms for a response to come back from origin from a previous request, until this request is allowed through.

I don't know if Squid has similar features, it seems to have a 30,000ms timeout, which is not tunable. It also seems incredibly high.

...

There is a plugin that implements the Stale While Revalidate cache-control directive, which is documented in RFC 5861. This directive allows caches to serve a stale object while a background revalidation is occurring. When a popular object becomes stale, subsequent requests would be proxied to the origin for revalidation. With this plugin (and the appropriate Cache-control: directive), you are allowed to serve objects stale in cache, while one request goes to origin to fetch the new version. Combined with read-while-write, and the fuzzy logic feature, this is a good alternative to the Open-Retry feature. The downside is that the current implementation is not complete, and needs changes to the core / cache to solve the problem completely.

...