Many thanks for the pointer!
If I understand this correctly, there are some implications following
session_linger:
1. High values require also large thread pools to make up for the
lingering sessions ?
2. Low values are safer but may result in increased CPU usage ?
3. The effectiveness of session_linger depends on the network latency:
if requests are piped in at a slow rate more sessions are locked up waiting?
If 3 is correct then session_linger sounds like a dangerous toy, because
I can't really control the network latency.
Regards,
G.
On 06.01.2011 01:00, Poul-Henning Kamp wrote:
In message<[email protected]>, George Georgovassilis writes:
1. The benchmark replicates an expected real-life sequence of requests
and workload from a single IP (namely a corporate web-proxy), thus
labelling it "synthetic" does it no justice :-)
Well, that depends on your proxy more than anything else, but I'll
take your word for it.
2. If you leave "session_linger" out of the configuration (so not
mentioning it at all) the benchmark still hangs. Whatever the default
value is, it doesn't work and I explicitly need to reduce it to 20.
The default is 50msec.
You can always get the full spiel, inclusive the default value
from the CLI:
param.show session_linger
200 1031
session_linger 50 [ms]
Default is 50
How long time the workerthread lingers on the
session to see if a new request appears right
away.
If sessions are reused, as much as half of all
reuses happen within the first 100 msec of the
previous request completing.
Setting this too high results in worker threads
not doing anything for their keep, setting it too
low just means that more sessions take a detour
around the waiter.
NB: We do not know yet if it is a good idea to
change this parameter, or if the default value is
even sensible. Caution is advised, and feedback
is most welcome.
_______________________________________________
varnish-misc mailing list
[email protected]
http://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
