Date: Tue, 25 Apr 2000 05:23:39 +0300 From: A G F Keahan <ak@freenet.co.uk> To: "Richard Seaman, Jr." <dick@seaman.org> Cc: Jason Evans <jasone@canonware.com>, freebsd-hackers@FreeBSD.ORG Subject: Re: Multithreaded server performance Message-ID: <390501AB.D185646E@freenet.co.uk> References: <3903AEA6.FA7CBBAB@freenet.co.uk> <20000423212115.E31925@sturm.canonware.com> <20000424164405.G370@seaman.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?390501AB.D185646E>