On Tue, Jan 11, 2011 at 5:35 AM, George Georgovassilis <[email protected]> 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 > [email protected] > http://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc > _______________________________________________ varnish-misc mailing list [email protected] http://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
