From owner-freebsd-hackers Mon Dec 20 17:45:16 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from canonware.com (canonware.com [207.20.242.18]) by hub.freebsd.org (Postfix) with SMTP id A0986153E6 for ; Mon, 20 Dec 1999 17:45:14 -0800 (PST) (envelope-from jasone@canonware.com) Received: (qmail 40040 invoked by uid 1001); 21 Dec 1999 01:43:42 -0000 Date: Mon, 20 Dec 1999 17:43:41 -0800 From: Jason Evans To: Chris Sedore Cc: Jason Evans , hackers@FreeBSD.ORG Subject: Re: Practical limit for number of TCP connections? Message-ID: <19991220174341.A39990@sturm.canonware.com> References: <19991220164517.F26743@sturm.canonware.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from cmsedore@maxwell.syr.edu on Mon, Dec 20, 1999 at 08:24:28PM -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Dec 20, 1999 at 08:24:28PM -0500, Chris Sedore wrote: > On Mon, 20 Dec 1999, Jason Evans wrote: > > 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. > > I don't disagree with any of what you have written. I'd expect you to > concede that it is true that the scalability is proportional. That is, > LinuxThreads (that is, rfork()) is probably not anything like optimally > scalable, but something like the last FreeBSD KSE model that I saw > bouncing around on -arch would do alot better. Yes, LinuxThreads has a number of scalability problems that make using even a relatively small number of threads perform quite poorly, especially if there are multiple multi-threaded applications running on the same machine. I have serious issues with the 1:1 approach that LinuxThreads uses, because it fails to perform reasonably for anything but a very constrained set of multi-threaded programming models. Jason To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message