SV: Re: Varnish stuck on stresstest/approved by real traffic
stockrt at gmail.com
Thu Nov 5 15:07:36 CET 2009
2009/11/5 Václav Bílek <v.bilek at 1art.cz>:
>>, and on 2.0.4 and older you will often use noticeably fewer threads (threads should no longer grow considerably larger than actual concurrent requests, which is somewhat counter intuitive)
I would like to say, about sess_linger, that when I tested it, all
things went ok, until I put synthetic load on the server and tried to
access it with no success from another client, using a browser, while
the synthetic load was getting all its requests served.
I tried somethng like:
thread_pool_min = 20
thread_pool_max = 200
thread_pools = 4
Number of synthetic concurrent clients: 80
All the 4*20 threads, 20 from each thread_pool, were occupied
"lingering", and no new thread have waken to serve my new connection
from the browser.
I was using linger 50ms, and certainly the synthetic load could make
requests interval less than that.
Also, I believe that putting 81 concurrent clients (much much fast
clients, cause they are synthetic load in the same network with
virtually no lag and no bandwidth limits) could start showing problems
in this load test, due to the lack of a new thread, which should be
started on-demand, the same problem I faced with my browser.
I think in real life linger should be ok, but I only use linger in
production with "preforked" threads, as in:
thread_pool_min = thread_pool_max
thread_pool_add_delay=1 to force the varnish to start serving as soon
as possible when we restart it.
Leaving threads configured to be created on-demand with sess_linger,
at least on 2.0.4, I think can cause you trouble if you have very fast
clients and bursts/peaks of requests.
MSN: stockrt at hotmail.com
GTalk: stockrt at gmail.com
More information about the varnish-misc