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