Connections dropped under load

[George Georgovassilis]

On 11.01.2011 12:54, Kristian Lyngstol wrote:
> On Tue, Jan 11, 2011 at 11:35:42AM +0100, George Georgovassilis wrote:
>> 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.
> It is true that this isn't explicitly documented, yet top-posting is not
> preferred on the Varnish lists. That it is not documented anywhere doesn't
> change that - it only means that you get the first offence for free. It
> wasn't my intention to berate you, but I would like the mail to this list
> to be of the traditional mail list type.
>
> The reason is simple: I often keep up with 5-6 threads of communication on
> the very same list. To be able to accomplish that, it's a great help if I
> have some context to deal with when you are writing. It's not much to ask
> for.
>
> If you continue to top post even after being hinted that you should not,
> you are essentially being rude to the people who would help you. It's true
> that others top-post too, but that's not an excuse for you to continue
> doing so. The reality is that top-posting leads to less focused replies,
> missed questions and eventually a departure of some of the most experienced
> users and developers from the mail lists because we don't want to cope with
> it. And eventually you end up with the blind leading the blind.
>
> It's a difference of ego: Top-posting might be easier to write, but it is
> by far harder to read on a busy mail list. If you can't be bothered to
> invest time in writing your mail, why should I be bothered to read it - let
> alone answer you.
>
> As for whatever arguments exist FOR top-posting, I really do not care. In
> my experience, the people who top-post and continue to do so are the
> members of the community that are least willing to truly contribute in a
> positive manner. I usually assume that top-posting is based on ignorance,
> not malice, but continued top-posting can't be seen as anything but malice.
>
>> 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].
> Simply put: If your virtual solution limits your usage of threads, then
> picked the wrong virtual solution to run Varnish on.
>
> If you take a look at the architecture notes[1], you'll see what I'm
> talking about. Varnish is designed for high-end servers and environments,
> but works just fine under low-end systems too. I'm fairly sure my mail
> didn't say anything about requiring high-end hardware, but I don't really
> know, since your quoting style doesn't let me easily check what precisely
> you are replying to. I suspect you are just being inaccurate in your
> response. Rest assure that I catch details for better or worse - and I use
> them in my replies. If I say it's designed for high-end hardware, that does
> NOT mean that high-end hardware is required. You don't have to run just
> because you are wearing running shoes.
>
> However, limiting the number of threads is not something that is strongly
> affected by hardware at all. And there are many virtual environments
> that will have no trouble at all using threads heavily. That puts your
> particular environment into what I like to call the "Nintendo"-category:
> It's not a real platform anymore and if it works, then that's fun and nice
> and all of that, but if it doesn't, it's not something that we should
> divert resources to.
>
> That you did not state up-front that this was a virtual environment which
> put artificial limits on thread-usage is regrettable, but not a big deal.
> In that regard, I'm more worried about all the people who tried to help you
> without querying for those rather important (and easily available) details.
>
> This will be the last reply I send to you if you keep top posting. Your
> choice.
>
> [1] http://www.varnish-cache.org/trac/wiki/ArchitectNotes
>
> - Kristian

Hello Kristian,

It's your home, I'm just a guest passing by - sorry I didn't bring any 
gifts :-(
Yes, Ninteno it's a good term describing that environment. Only that 
there is/might be a whole lot of them which need to be fed with 
connections. An army of lemmings if you will. So I guess that, even if I 
get a rather big virtual box with plenty of RAM and CPU, I still won't 
be able to handle all the requests if the sysadmin limited the thread 
count. I take that there is also no way to handle all incoming 
connections as a single point of entry if threads are limited.

An unrelated question springs to my mind, which fortunately doesn't 
happen to be my use case: how would varnish handle a COMET scenario with 
tens of thousands of active connections, i.e. as a proxy for Jetty or 
Tomcat6 ?

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