The basics

Request Collapsing causes simultaneous cache misses within a single Fastly datacenter to be "collapsed" into a single request to an origin server. While the single request is being processed by the origin, the other requests wait in a queue for it to complete. Two types of Request Collapsing exist:

Collapsing on a single cache server

Collapsing within the datacenter between cache servers

Each cache server will automatically queue duplicate requests for the same hash and only allow one request to origin. You can disable this behavior by setting req.hash_ignore_busy to true in vcl_recv.

Within a datacenter, not every cache stores every object. Only two servers in each datacenter will store an object: one as a primary and one as a backup. Only those two servers will fetch the object from origin.

How it works

In Fastly's version of Varnish, VCL subroutines often run on different caches during a request. For a particular request, both an edge cache and a shield cache will exist (though a single cache can, in some cases, fulfill both of these roles). The edge cache receives the HTTP request from the client and determines via a hash which server in the datacenter is the shield cache. If this cache determines it is the shield cache and has the object in cache, it fulfills both the edge cache and the shield cache roles.

Certain VCL subroutines run on the edge cache and some on the shield cache:

Edge Cache: vcl_recv, vcl_deliver, vcl_log, vcl_error

Shield Cache: vcl_miss, vcl_hit, vcl_pass, vcl_fetch, vcl_error

Determining if a cache is an edge or a shield

The fastly_info.is_cluster_edge VCL variable will be true if the cache currently running the VCL is the edge cache and false if it is the shield cache.

Caveats

Keep in mind the following limitations when using the Request Collapsing feature:

Any req.http.* headers are not transferred from the shield cache back to the edge cache. Remember this when writing advanced configurations that use headers to keep track of state. If you set a req.http.* header in any of the subroutines that run on the shield cache, expect that the change will not persist on the edge cache.

A single, slow request to origin can sometimes cause a great many other requests for the same object to hang and fail. Because many requests for a single object are being collapsed down to one, they all succeed or fail based on the request that reaches the origin.

Was this guide helpful?

Yes
No

Tell us what worked and what we could do better.

Do not use this form to send sensitive information. If you need assistance, contact support@fastly.com.