Connections dropped under load

[David Birdsong]

On Tue, Jan 11, 2011 at 5:35 AM, George Georgovassilis
<g.georgovassilis at gmail.com> wrote:
> 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].
Dont let the door hit you on the way out.

>
> 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
>
>
> _______________________________________________
> varnish-misc mailing list
> varnish-misc at varnish-cache.org
> http://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
>