+</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
+<div class="section">
+<h2><a name="thunderingherd" id="thunderingherd">Avoiding the Thundering Herd</a></h2>
+ <p>When a cached entry becomes stale, <code class="module"><a href="../mod/mod_cache.html">mod_cache</a></code> will submit
+ a conditional request to the backend, which is expected to confirm whether the
+ cached entry is still fresh, and send an updated entity if not.</p>
+ <p>A small but finite amount of time exists between the time the cached entity
+ becomes stale, and the time the stale entity is fully refreshed. On a busy
+ server, a significant number of requests might arrive during this time, and
+ cause a <strong>thundering herd</strong> of requests to strike the backend
+ suddenly and unpredicably.</p>
+ <p>To keep the thundering herd at bay, the <code class="directive">CacheLock</code>
+ directive can be used to define a directory in which locks are created for
+ URLs <strong>in flight</strong>. The lock is used as a <strong>hint</strong>
+ by other requests to either suppress an attempt to cache (someone else has
+ gone to fetch the entity), or to indicate that a stale entry is being refreshed
+ (stale content will be returned in the mean time).
+ </p>
+ <h3>Initial caching of an entry</h3>
+
+ <p>When an entity is cached for the first time, a lock will be created for the
+ entity until the response has been fully cached. During the lifetime of the
+ lock, the cache will suppress the second and subsequent attempt to cache the
+ same entity. While this doesn't hold back the thundering herd, it does stop
+ the cache attempting to cache the same entity multiple times simultaneously.
+ </p>
+
+ <h3>Refreshment of a stale entry</h3>
+
+ <p>When an entity reaches its freshness lifetime and becomes stale, a lock
+ will be created for the entity until the response has either been confirmed as
+ still fresh, or replaced by the backend. During the lifetime of the lock, the
+ second and subsequent incoming request will cause stale data to be returned,
+ and the thundering herd is kept at bay.</p>
+
+ <h3>Locks and Cache-Control: no-cache</h3>
+
+ <p>Locks are used as a <strong>hint only</strong> to enable the cache to be
+ more gentle on backend servers, however the lock can be overridden if necessary.
+ If the client sends a request with a Cache-Control header forcing a reload, any
+ lock that may be present will be ignored, and the client's request will be
+ honoured immediately and the cached entry refreshed.</p>
+ <p>As a further safety mechanism, locks have a configurable maximum age.
+ Once this age has been reached, the lock is removed, and a new request is
+ given the opportunity to create a new lock. This maximum age can be set using
+ the <code class="directive">CacheLockMaxAge</code> directive, and defaults to 5
+ seconds.
+ </p>
+
+ <h3>Example configuration</h3>
+
+ <div class="example"><h3>Enabling the cache lock</h3><p><code>
+ #<br />
+ # Enable the cache lock<br />
+ #<br />
+ <IfModule mod_cache.c><br />
+ <span class="indent">
+ CacheLock on<br />
+ CacheLockPath /tmp/mod_cache-lock<br />
+ CacheLockMaxAge 5<br />
+ </span>
+ </IfModule>
+ </code></p></div>
+