Connections dropped under load

Tue Jan 11 11:35:42 CET 2011

Hello Kristian,

Personally I'm cool with either way of posting, a quick scan of the mail 
archives showed that both were being practised and I couldn't find any 
posting rules in the maillist desc - so (even at the risk that you do 
mind) I'll stay with top posting... the modern internet has evolved past 
this discussion [1] and I really can't be bothered. Sorry.

I do appreciate immensely your (all of your) precious insights and hints 
which help me understand (I'm neither particularly familiar with 
networking or OSes, I  outsource these tasks to the corresponding 
software vendors :-) in which way exactly the resource needs of my 
application can be met. (Un)fortunately the hype around cloud 
environments has gotten to the people who pay my checks, and I can't 
ignore these restrained environments that come at hundreds of instances 
- even if you have the enviable luxury of doing so. The high latency 
connections between the cloud instances make a software like varnish 
excruciatingly necessary in order to avoid as many as possible 
roundtrips to the nodes behind.

Please also note that in no way the Varnish documentation (see chapter 
on prerequisites [2]) mentions a high-end server for even moderate loads 
(I iterate: we are talking here about lousy 700 req/s), and keep in mind 
that this discussion has turned to a "virtual" resource: it's not about 
memory or CPU power but a logical division of such, namely threads. I do 
take the point however that when it comes to scalability nginx might be 
a better choice [3].

Many thanks,
G.

[1] https://secure.wikimedia.org/wikipedia/en/wiki/Posting_style
[2] http://www.varnish-cache.org/docs/2.1/installation/prerequisites.html
[3] 
http://highscalability.com/display/Search?searchQuery=nginx&moduleId=4876569

On 11.01.2011 10:51, Kristian Lyngstol wrote:
>      If that is inconvenient, I suggest not top-posting.
> PS: This mail is optimized for bottom-to-top reading.
>
> Kristian
> Regards,
>
> performance.
> expect to use a piece of software written for and optimized for high-end
> than enough threads. If you can't use a half-decent machine, then you can't
> we'll try to solve. Any half-decent virtual machine will let you use more
> don't really have any actual limits relevant to Varnish, is not a problem
> That some systems operate with artificially set limits on resources that
> operating environments, and we don't really care about number of threads.
> Varnish is written for modern computers, modern systems and modern
>
> Hi George,
>
> On Tue, Jan 11, 2011 at 10:09:00AM +0100, George Georgovassilis wrote:
>> Hello Kristian,
>>
>> Thank you for summarizing - the relation between threads, session
>> linger and connection handling has been explored indeed sufficiently
>> in this thread. The advice of increasing the thread pool size is one
>> that is not always easy to follow though. I'm running my app on a
>> virtual machine (think Open VMS or EC2) and there is a low thread
>> limit, so naturally I'm exploring ways of keeping that low
>> especially since the application server behind varnish is also
>> competing for them. nginx can as far as I know serve thousand of
>> connections with just two worker threads, I erroneously assumed when
>> first evaluating varnish that it was using a similar technique.
>>
>> Regs,
>> G.
>>
>>
>> On 11.01.2011 08:48, Kristian Lyngstol wrote:
>>> thanks.
>>> posting,
>>> top
>>> stop
>>> Please
>>>
>>> On Tue, Jan 11, 2011 at 12:59:58AM +0100, George Georgovassilis wrote:
>>>> Thank you for the hint. Here are the values:
>>>>
>>>> thread_pools = 2
>>>> thread_pool_min = 2
>>>> thread_pool_max = 200 (was 2 at the time of my initial tests)
>>>> thread_pool_add_delay = 2
>>> As have already been pointed out, this is a low value. This also explains
>>> why session_linger is an issue to you. Unless you are on 32-bit (which you
>>> shouldn't ever ever ever be), there's no reason to not always have a
>>> thousand threads laying around. Your settings also means that you have FOUR
>>> threads available when you start your tests. Not exactly a lot of room for
>>> bursts of traffic.
>>>
>>> Your other mail actually had a thread_pool_max of 16. That will give you a
>>> maximum of 16 concurrent requests that can be handled, with an other 32
>>> that can be queued. With session_linger, these threads will remain
>>> allocated to the connection for a longer duration, thus it's obvious that
>>> in this case, your thread starvation was the real issue and you just
>>> triggered it faster with a higher session_linger. It's a perfectly obvious
>>> and mystery-free explanation. Session lingering is a mechanism to avoid
>>> trashing your system during high load by constantly moving data around
>>> between threads, but it depends on reasonable thread-settings - or rather:
>>> an abundance of threads.
>>>
>>> http://kristianlyng.wordpress.com/2010/01/26/varnish-best-practices/ sounds
>>> like a good place to start reading. Specially about threads.
>>>
>>> - Kristian

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-misc/attachments/20110111/07a7b60a/attachment-0003.html>