Date: Mon, 24 Apr 2000 17:46:51 -0500 From: Vladik <pvlad@bigfoot.com> To: A G F Keahan <ak@freenet.co.uk> Cc: freebsd-hackers@freebsd.org Subject: Re: Multithreaded server performance Message-ID: <00042417473901.01311@baikal> In-Reply-To: <390501AB.D185646E@freenet.co.uk> References: <3903AEA6.FA7CBBAB@freenet.co.uk> <20000424164405.G370@seaman.org> <390501AB.D185646E@freenet.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello, I would like to suggest to read the following articles at http://www.cs.wustl.edu/~schmidt/report-doc.html (he has there a ps doc for each article) -------------------------------- 13.Comparing Alternative Programming Techniques for Multi-threaded Servers -- the Thread-per-Session Concurrency Model, SIGS, Vol 8. No 7. July 1996. This column examines and evaluates three techniques for developing multi-threaded servers using the ``thread-per-session'' concurrency model. These techniques include using the socket network programming interface, using C++ wrappers for sockets, and using multi-threaded Orbix. 14.Comparing Alternative Programming Techniques for Multi-threaded Servers -- the Thread-Pool Concurrency Model, SIGS, Vol 8. No 4. April 1996. This column examines and evaluates three techniques for developing multi-threaded servers using the ``thread-pool'' concurrency model. These techniques include using the socket network programming interface, using C++ wrappers for sockets, and using multi-threaded Orbix. 15.Comparing Alternative Programming Techniques for Multi-threaded Servers -- the Thread-per-Request Concurrency Model, SIGS, Vol 8. No 2. February 1996. This column examines and evaluates four techniques for developing multi-threaded servers using the ``thread-per-request'' concurrency model. These techniques include using the socket network programming interface, using C++ wrappers for sockets, and using two multi-threaded versions of CORBA (Orbix and HP ORB Plus). ------------------------------------------------------------------------ I hope those papers will help you to decide what thread model to use for your particular application. Most of the models, I think, are implemented in the ACE C++ toolkit, but I am not 100% sure (but for sure you do not need to be concerned with any CORBA's if you just want to use the described thread models) I found that for applications that use any OS or other resources that are expensive to tear down (like database connection, sockets, etc) thread pool models work the best, because there a programmer has control over what resources to can be bound to the items in the pool. Regards, Vladislav On Mon, 24 Apr 2000, A G F Keahan wrote: > 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 -- .. -- 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?00042417473901.01311>