From owner-freebsd-hackers Mon Apr 24 18:51:32 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from alpha.netvision.net.il (alpha.netvision.net.il [194.90.1.13]) by hub.freebsd.org (Postfix) with ESMTP id 9710A37BC75 for ; Mon, 24 Apr 2000 18:51:23 -0700 (PDT) (envelope-from ak@freenet.co.uk) Received: from freenet.co.uk (RAS1-p120.rlz.netvision.net.il [62.0.168.122]) by alpha.netvision.net.il (8.9.3/8.8.6) with ESMTP id EAA23699; Tue, 25 Apr 2000 04:21:48 +0300 (IDT) Message-ID: <390501AB.D185646E@freenet.co.uk> Date: Tue, 25 Apr 2000 05:23:39 +0300 From: A G F Keahan X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 4.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: "Richard Seaman, Jr." Cc: Jason Evans , freebsd-hackers@FreeBSD.ORG Subject: Re: Multithreaded server performance References: <3903AEA6.FA7CBBAB@freenet.co.uk> <20000423212115.E31925@sturm.canonware.com> <20000424164405.G370@seaman.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jason and Richard, thank you very much for your explanations of libc_r and LinuxThreads. Due to the significant processing time of each request (typically between 50-800ms, averaging 100ms), I doubt that FreeBSD's threads would perform any worse than if I forked a separate process for each connection (memory usage would go sky high), or even if I had a single process and called poll() myself to check each descriptor for being readable/writable. What worries me though is that by design client connections are kept alive (although the server is allowed to disconnect a client after a period of inactivity), hence after a while there will be a lot of idle descriptors, and continuously polling them might slow down the processing of the active ones. I have to experiment to find out what's best -- the goal is to do better than NT (which surprisingly does quite a good job when it comes to processing lots of threads). Solaris's threads are pretty darn good too, but I dislike all things SystemV-ish, and Solaris/x86 isn't all that hot either (compared with the version for the UltraSPARC). > On Sun, Apr 23, 2000 at 09:21:15PM -0700, Jason Evans wrote: > > On Mon, Apr 24, 2000 at 05:17:10AM +0300, A G F Keahan wrote: > > > I am currently porting a multithreaded TCP server from NT (yech!) to > > > UNIX using pthreads. The server has a fairly straightforward design -- > > > it opens a thread for each connection, and each thread spends most of > > > its life blocked in a call to read() from a socket. As soon as it > > > receives enough of a request, it does quite a bit of processing and > > > sends something back to the client. > > > > This design isn't ideal on any OS, but the fact that you do significant > > processing every time a request arrives on a socket probably hides most of > > the inefficiency due to thread switching and lack of cache locality due to > > many thread stacks. Can you suggest a better design for this type of server application under FreeBSD? Perhaps a combination of forking (or pre-forking) and threads? > > > How would FreeBSD 4.0 perform in such a scenario? We are talking > > > hundreds, maybe thousands of threads, a lot of them doing blocking reads > > > and writes. Is the standard pthreads library adequate for the task, or > > > would "Linuxthreads" be a better choice? What is the main difference > > > between the standard FreeBSD pthreads and "Linuxthreads" -- it seems > > > both are implemented using a version of clone(). > > > > FreeBSD's threads should perform adequately given the design of your program > > and the hardware you listed. Actually trying it on the various operating > > systems would be a good exercise, but I have found that FreeBSD's threads > > perform at least as well as Solaris's for such an application. > > Interesting. I would have thought Solaris would be much superior. I would have thought so too... we'll see. Thanks again Alex Keahan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message