<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<font size="-1"><font face="Verdana">Hello Kristian,<br>
<br>
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.<br>
<br>
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. <br>
<br>
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 </font></font><font size="-1"><font
face="Verdana">[3]</font></font><font size="-1"><font
face="Verdana">. <br>
<br>
Many thanks,<br>
G.<br>
<br>
[1] <a class="moz-txt-link-freetext" href="https://secure.wikimedia.org/wikipedia/en/wiki/Posting_style">https://secure.wikimedia.org/wikipedia/en/wiki/Posting_style</a><br>
</font></font>[2]
<a class="moz-txt-link-freetext" href="http://www.varnish-cache.org/docs/2.1/installation/prerequisites.html">http://www.varnish-cache.org/docs/2.1/installation/prerequisites.html</a><br>
[3]
<a class="moz-txt-link-freetext" href="http://highscalability.com/display/Search?searchQuery=nginx&moduleId=4876569">http://highscalability.com/display/Search?searchQuery=nginx&moduleId=4876569</a><br>
<br>
On 11.01.2011 10:51, Kristian Lyngstol wrote:
<blockquote cite="mid:20110111095112.GC2266@freud" type="cite">
<pre wrap=""> 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:
</pre>
<blockquote type="cite">
<pre wrap="">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:
</pre>
<blockquote type="cite">
<pre wrap="">thanks.
posting,
top
stop
Please
On Tue, Jan 11, 2011 at 12:59:58AM +0100, George Georgovassilis wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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
</pre>
</blockquote>
<pre wrap="">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.
<a class="moz-txt-link-freetext" href="http://kristianlyng.wordpress.com/2010/01/26/varnish-best-practices/">http://kristianlyng.wordpress.com/2010/01/26/varnish-best-practices/</a> sounds
like a good place to start reading. Specially about threads.
- Kristian
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
</blockquote>
<font size="-1"><font face="Verdana"><br>
</font></font>
</body>
</html>