Date: Mon, 20 Dec 1999 16:45:17 -0800 From: Jason Evans <jasone@canonware.com> To: Chris Sedore <cmsedore@maxwell.syr.edu> Cc: Alfred Perlstein <bright@wintelcom.net>, Kevin Day <toasty@dragondata.com>, "Ronald F. Guilmette" <rfg@monkeys.com>, hackers@FreeBSD.ORG Subject: Re: Practical limit for number of TCP connections? Message-ID: <19991220164517.F26743@sturm.canonware.com> In-Reply-To: <Pine.BSF.4.05.9912191455490.72333-100000@qwerty.maxwell.syr.edu>; from cmsedore@maxwell.syr.edu on Sun, Dec 19, 1999 at 03:01:41PM -0500 References: <Pine.BSF.4.21.9912181523530.12109-100000@fw.wintelcom.net> <Pine.BSF.4.05.9912191455490.72333-100000@qwerty.maxwell.syr.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Dec 19, 1999 at 03:01:41PM -0500, Chris Sedore wrote: > > > On Sat, 18 Dec 1999, Alfred Perlstein wrote: > > > On Sat, 18 Dec 1999, Kevin Day wrote: > > > > > > The _clean_ way of doing it would be to write your multi-user server using > > > > threads, and to assign one thread to each connection. If you can do that, > > > > then the logic in the program becomes quite simple. Each thread just sits > > > > there, blocked on a call to read(), until something comes in, and then it > > > > just parses the command, does whatever it is supposed to do in response to > > > > that command, and then goes back to the read() again. > > > > > > > > But as I understand it, there is not yet sufficient threads support in the > > > > FreeBSD kernel to make this work well/properly. (I may perhaps be misinformed > > > > about that, but that's what I have been told anyway.) > > > > > > I believe this is how ConferenceRoom works, so it seems ok, but I remember > > > the comments that FreeBSD was their least preferred platform because of > > > thread problems. > > > > Using a thread per connection has always been a bogus way of programming, > > it's easy, but it doesn't work very well. > > Ahem. Well, that kind of depends on the threads implementation, how many > connections you're talking about, and likely some other factors too. > I've got an NT box that handles about 1000 concurrent connections with > 1000 (plus a few) threads doing the work. Runs fine, performs very well. > > I wouldn't argue that it is the most scalable solution to problems, but it > is easier, and scales proportionally to the quality of the threads > implementation. 1000 simultaneous connections really isn't that many, but even at 1000 threads, you could likely achieve much better performance by using thread pools or a simple poll() loop rather than one thread per connection. Why? Locality, locality, locality. Consider that each thread has its own stack, which in the best of worlds would be 4K, but is more likely at least 16K. Now, start switching between threads to handle relatively small amounts of I/O for each connection, and consider what that does to the VM, not to mention the memory hierarchy of the hardware. You might as well not even have L2 cache, because the program will thrash the cache so badly. Of course, you won't see worst case performance if client activity is unevenly distributed, but you just can't get past the fact that the memory footprint of one thread per connection is larger than a bounded pool of threads. Some threads implementations are better than others at handling such abuses, but the performance of such an approach will almost always suffer in comparison to a design that takes locality into consideration. I disagree with your assessment that scalability of one thread per connection is proportional to the quality of the threads implementation. An ideal threaded program would have exactly as many threads as available processors, and the threads would always be runnable. Of course, real-world applications almost never work that way, but the goal of a programmer should be to have as few threads as possible while still achieving maximal parallelism. If connection scalability is an issue, using one thread per connection ignores a critical aspect of high performance threaded application design. Jason To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19991220164517.F26743>