[prev in list] [next in list] [prev in thread] [next in thread] 

List:       varnish-dev
Subject:    Re: ban_lurker_age, ban_lurker_sleep
From:       "Poul-Henning Kamp" <phk () phk ! freebsd ! dk>
Date:       2016-04-19 19:33:17
Message-ID: 75941.1461094397 () critter ! freebsd ! dk
[Download RAW message or body]

--------
In message <57152FD8.8090705@schokola.de>, 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
phk@FreeBSD.ORG         | 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
varnish-dev@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
[prev in list] [next in list] [prev in thread] [next in thread]