[experimental-ims] 9bef407 more on bans, the lurker

Geoff Simmons geoff at varnish-cache.org
Wed Aug 31 16:01:44 CEST 2011


commit 9bef407d3f19337a804cf54505c6953f01e52957
Author: Per Buer <perbu at varnish-software.com>
Date:   Mon Aug 15 14:51:43 2011 +0200

    more on bans, the lurker

diff --git a/doc/sphinx/tutorial/purging.rst b/doc/sphinx/tutorial/purging.rst
index 873a687..ce1d945 100644
--- a/doc/sphinx/tutorial/purging.rst
+++ b/doc/sphinx/tutorial/purging.rst
@@ -89,9 +89,18 @@ they could issue::
 Quite powerful, really.
 
 Bans are checked when we hit an object in the cache, but before we
-deliver it. *An object is only checked against newer bans*. If you have
-a lot of objects with long TTL in your cache you should be aware of a
-potential performance impact of having many bans.
+deliver it. *An object is only checked against newer bans*. 
+
+Bans that only match against beresp.* are also processed by a
+background worker threads called the *ban lurker*. The ban lurker will
+walk the heap and try to match objects and will evict the matching
+objects. How aggressive the ban lurker is can be controlled by the
+parameter ban_lurker_sleep. 
+
+Bans that are older then the oldest objects in the cache are discarded
+without evaluation.  If you have a lot of objects with long TTL, that
+are seldom accessed you might accumulate a lot of bans. This might
+impact CPU usage and thereby performance.
 
 You can also add bans to Varnish via HTTP. Doing so requires a bit of VCL::
 



More information about the varnish-commit mailing list