-------- In message <[email protected]>, Nils Goroll writes:
>This probably is the scenratio which is most relevant for cases of good use of >the ban lurker. The case I'm working on is 40k expensive bans on 400k objects >when the ban luker cannot keep up for long periods of time (yes, I know this is >bad use of bans, but still an intersting case). > >With such numbers of bans, avoiding ban tests at lookup time should be >relevant, so kicking in the lurker early should help. Well, depends what you want helped I guess :-) Either way, that's why it is a parameter, I'm sure there's no one size that fits everybody. >As long as the ban lurker is single threaded, it's pretty hard rate-limited >already on any real-life system of relevance. Not really, there are many systems where the full attention of the ban lurker is undesirable. For instance a system with a gazillion objects where a single ban is used to take out a handful of objects because of some one-off mistake. In that scenario it is much better to let the req-time validations do the job, than having the lurker go full tilt and page in the entire cache. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [email protected] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. _______________________________________________ varnish-dev mailing list [email protected] https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
