Connections dropped under load

Poul-Henning Kamp phk at phk.freebsd.dk
Thu Jan 6 01:00:25 CET 2011


In message <4D250296.2000601 at gmail.com>, 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.


-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at 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.




More information about the varnish-misc mailing list