Re: Multithreaded server performance
I have run threaded tests on Solaris with over 30,000 connections without problems, other than kernel deadlock due to resource starvation when stuffing too many kernel-side socket buffers with data. Well there's your solution then. With Solaris you can multiplex hundreds/thousands of user threads to a couple of LWP's, depending on your load and target architecture/configuration. Regarding FreeBSD's model - will this become something similar to Solaris/UnixWare's LWP model, or retain a clean libc_r/rfork separation? Cheers, Alex. Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Multithreaded server performance
In message [EMAIL PROTECTED] "Brian O'Shea" writes: : I was under the impression that, because user thread scheduling is done : in user mode, a thread that goes to sleep calling a blocking read() : system call will put the entire process to sleep until that read() : returns (and so all user threads in the process will also be blocked). : Is this correct? No. the pthreads wrappers only make you think that you are calling read, when in fact it multiplexes things behind the scenes for you. If one thread is reading, then another thread can be running. All this assumes that drivers implement select/poll correctly and nonblocking I/O is supported as well. Really a slick setup for when you need to do lots of threading, a big pain when you don't due to locking issues that come up when you trie to dice things into too many threads. But I digress. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Multithreaded server performance
Both Solaris and NT have good thread implementations: http://www.usenix.org/publications/library/proceedings/usenix-nt98/zabatta.html Read this paper -- There is something about NT threads implementation which has never been released in any books! 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). __ Do You Yahoo!? Talk to your friends online and get email alerts with Yahoo! Messenger. http://im.yahoo.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Multithreaded server performance
A G F Keahan wrote: On Sun, Apr 23, 2000 at 09:21:15PM -0700, Jason Evans wrote: 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? Preallocate a number of threads that yeilds adequate peformance and feed work to the threads via IPC mechanisms. When the thread finishes its work, rather than exiting, it just waits for another work unit. A simple way to do this is via a queue, or via a shared memory pool for each thread and a "go" semaphore. This avoids the overhead of thread startup and shutdown for every client connection. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Multithreaded server performance
From [EMAIL PROTECTED] Tue Apr 25 06:02:09 2000 Date: Tue, 25 Apr 2000 05:23:39 +0300 From: A G F Keahan [EMAIL PROTECTED] To: "Richard Seaman, Jr." [EMAIL PROTECTED] Cc: Jason Evans [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: Multithreaded server performance 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 There is a way to save from slowing down on lot of connections. If we assume that response time is not consired to be too fast, for example, 500-5000 msec, we can poll() not all sockets, but just delay inserting some sockets in polling set. Look how it works: 1. we've made socket action (accept, read etc) 2. insert socket into poll/select waiting set after N msec 3. if socket has any activity within M msec, go to 1. 4. delay socket insertion on L msec If some of connections require most interactivity, they must use its own L,M,N. Only overhead we have is supporting two queues of active and frozen sockets. So, by variation L,M,N we have array of only 32 descriptors for poll() and really work with about 1000 sockets, working in single process without treads and forks. Sincerely your, Cyril A. Vechera To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Multithreaded server performance
Linux runs into problems at less than 4000 threads because of a limit on the total number of processes, even if the thread stack size is decreased. 16xxx if you use a 2.3.99pre-x kernel? At least I thought that that was being mentioned as one of the major new things in 2.4.x kernels. Marco van de Voort ([EMAIL PROTECTED]) http://www.stack.nl/~marcov/xtdlib.htm To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Multithreaded server performance
On Sun, Apr 23, 2000 at 09:21:15PM -0700, Jason Evans wrote: FreeBSD's libc_r does not use clone() or anything similar. Instead, it is a userland call conversion library that multiplexes threads in a single process. This style of threads library should perform well for the type of application you are dealing with. I was under the impression that, because user thread scheduling is done in user mode, a thread that goes to sleep calling a blocking read() system call will put the entire process to sleep until that read() returns (and so all user threads in the process will also be blocked). Is this correct? If it is, it sounds like a user thread implementation would be bad for Mr. Keahan's application, and something like the LinuxThreads port might be more appropriate. Note that there is also ports/devel/linuxthreads, which is based on rfork(), which can be made to behave like Linux's clone(). Jason Please correct me if I am wrong. Thanks, -brian -- Brian O'Shea [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Multithreaded server performance
On Mon, 24 Apr 2000, Brian O'Shea wrote: On Sun, Apr 23, 2000 at 09:21:15PM -0700, Jason Evans wrote: FreeBSD's libc_r does not use clone() or anything similar. Instead, it is a userland call conversion library that multiplexes threads in a single process. This style of threads library should perform well for the type of application you are dealing with. I was under the impression that, because user thread scheduling is done in user mode, a thread that goes to sleep calling a blocking read() system call will put the entire process to sleep until that read() returns (and so all user threads in the process will also be blocked). Is this correct? 1. You are mistaken. If it is, it sounds like a user thread implementation would be bad for Mr. Keahan's application, and something like the LinuxThreads port might be more appropriate. Note that there is also ports/devel/linuxthreads, which is based on rfork(), which can be made to behave like Linux's clone(). Jason Please correct me if I am wrong. Go To 1. ;-) -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Multithreaded server performance
On Mon, Apr 24, 2000 at 06:13:53AM -0400, Daniel Eischen wrote: On Mon, 24 Apr 2000, Brian O'Shea wrote: I was under the impression that, because user thread scheduling is done in user mode, a thread that goes to sleep calling a blocking read() system call will put the entire process to sleep until that read() returns (and so all user threads in the process will also be blocked). Is this correct? 1. You are mistaken. Could you elaborate? The text that I am using [1] warns about blocking system calls putting the process (and thus all user threads) to sleep. This book has no FreeBSD specific information, so anything specific to FreeBSD would be really interesting to hear. Please correct me if I am wrong. Go To 1. ;-) -- Dan Eischen Thanks, -brian 1. Norton, Scott J., "Thread Time", p.24, Hewlett-Packard Professional Books, ISBN 0-13-190067-6 -- Brian O'Shea [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Multithreaded server performance
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. 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. LinuxThreads will definitely bog down with so many threads because the kernel scheduler has to deal with so many clone()d processes. Somewhat. But its nothing compared to the slowdown in the libc_r scheduler, in my experience. Each context switch (or each time the libc_r scheduler examines its state to consider a context switch), it executes a poll call to examine the state of *each* file descriptor that is considered "blocked" (of course its not really blocked in the kernel -- libc_r converts all i/o calls to non-blocking and polls their status to determined when i/o can be done). If you have hundreds/thousands of threads and each has an open file descriptor that has to be polled, linuxthreads is much faster, at least for the tests I've run. However, linuxthreads will consume a lot more kernel resources, so this only holds if you can tolerate the load on your resources. That said, if you want more than 1022 threads using linuxthreads (either in the FreeBSD port or in linux emulation, or in native linux) you will have to tweak the linuxthreads pthread library. It has a default limit of 1024 threads including the "main" thread and the thread manager thread. You have to raise the limit, and fiddle with the default thread stack spacing, if I recall. (I think the default stack spacing is 2MB. This doesn't work too well when you have "thousands" of threads :)) FreeBSD's libc_r does not use clone() or anything similar. Instead, it is a userland call conversion library that multiplexes threads in a single process. This style of threads library should perform well for the type of application you are dealing with. Perhaps. The proposed "new" threads model that I understand you are working on should be *much* superior in this kind of application to either libc_r or linuxthreads, I would think. -- Richard Seaman, Jr.email: [EMAIL PROTECTED] 5182 N. Maple Lane phone:262-367-5450 Chenequa WI 53058fax:262-367-5852 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Multithreaded server performance
On Monday, April 24, 2000, Brian O'Shea wrote: On Mon, Apr 24, 2000 at 06:13:53AM -0400, Daniel Eischen wrote: On Mon, 24 Apr 2000, Brian O'Shea wrote: I was under the impression that, because user thread scheduling is done in user mode, a thread that goes to sleep calling a blocking read() system call will put the entire process to sleep until that read() returns (and so all user threads in the process will also be blocked). Is this correct? 1. You are mistaken. Could you elaborate? The text that I am using [1] warns about blocking system calls putting the process (and thus all user threads) to sleep. This book has no FreeBSD specific information, so anything specific to FreeBSD would be really interesting to hear. FreeBSD's threads implement has its own read() function which will make a non-blocking read() call (using the _real_ syscall) for the specified amount of bytes. Now a non-blocking read() call fails unless all the data in nbytes can be read into buf. So our implementation will continue to do a non-blocking read until all the data can be copied and then allows the thread continue, thus blocking only the calling thread. At least that's what the source code tells me. -- |Chris Costello [EMAIL PROTECTED] |I smell a wumpus. `-- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Multithreaded server performance
On Mon, Apr 24, 2000 at 04:44:05PM -0500, Richard Seaman, Jr. wrote: On Sun, Apr 23, 2000 at 09:21:15PM -0700, Jason Evans wrote: 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. LinuxThreads will definitely bog down with so many threads because the kernel scheduler has to deal with so many clone()d processes. Somewhat. But its nothing compared to the slowdown in the libc_r scheduler, in my experience. Each context switch (or each time the libc_r scheduler examines its state to consider a context switch), it executes a poll call to examine the state of *each* file descriptor that is considered "blocked" (of course its not really blocked in the kernel -- libc_r converts all i/o calls to non-blocking and polls their status to determined when i/o can be done). If you have hundreds/thousands of threads and each has an open file descriptor that has to be polled, linuxthreads is much faster, at least for the tests I've run. However, linuxthreads will consume a lot more kernel resources, so this only holds if you can tolerate the load on your resources. Interesting. Unfortunately, when I was developing the server I referred to, I was never able to get past about 100 connections on FreeBSD without crashing the kernel, because of the static buffer limits in the kernel (yes, I manually specified very large mbuf limits). As a result, I never experienced the scaling problems you mention. =) Linux runs into problems at less than 4000 threads because of a limit on the total number of processes, even if the thread stack size is decreased. I have run threaded tests on Solaris with over 30,000 connections without problems, other than kernel deadlock due to resource starvation when stuffing too many kernel-side socket buffers with data. FreeBSD's libc_r does not use clone() or anything similar. Instead, it is a userland call conversion library that multiplexes threads in a single process. This style of threads library should perform well for the type of application you are dealing with. Perhaps. The proposed "new" threads model that I understand you are working on should be *much* superior in this kind of application to either libc_r or linuxthreads, I would think. I hope so, because it's going to be a bit of work. =) Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Multithreaded server performance
On Mon, Apr 24, 2000 at 02:11:11PM -0700, Jason Evans wrote: Could you elaborate? The text that I am using [1] warns about blocking system calls putting the process (and thus all user threads) to sleep. This book has no FreeBSD specific information, so anything specific to FreeBSD would be really interesting to hear. 1. Norton, Scott J., "Thread Time", p.24, Hewlett-Packard Professional Books, ISBN 0-13-190067-6 Read page 25 as well. Call conversion (referred to as wrappers) is discussed there. Call conversion works very well for sockets. Wow, a page reference to the same book that I am reading. Kind of embarrassing that the answer to my question was on the page after the one that I mentioned. Thanks, that's exactly what I was looking for. -brian Jason -- Brian O'Shea [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Multithreaded server performance
Linux runs into problems at less than 4000 threads because of a limit on the total number of processes, even if the thread stack size is decreased. I believe this restriction was eliminated in the 2.2.x series. -MB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Multithreaded server performance
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 [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Multithreaded server performance
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
Re: Multithreaded server performance
On Monday, April 24, 2000, Brian O'Shea wrote: Yea, I took a look at lib/libc_r/uthread/uthread_read.c too, but it didn't paint the whole picture for me. Specifically, I couldn't find the definition for the _thread_sys_read() function. It looks like the polling magic to which Jason Evans referred occurs in some interesting code in uthread_kern.c, though. _thread_sys_read() is the real read(2) syscall. They're renamed to ``_thread_sys_SYSCALL()'' for the purpose of reimplementing them in a thread-friendly manner, as you see with read() there. -- |Chris Costello [EMAIL PROTECTED] |Do something unusual today. Accomplish work on the computer. `- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Multithreaded server performance
On Mon, Apr 24, 2000 at 05:07:00PM -0500, Chris Costello wrote: FreeBSD's threads implement has its own read() function which will make a non-blocking read() call (using the _real_ syscall) for the specified amount of bytes. Now a non-blocking read() call fails unless all the data in nbytes can be read into buf. So our implementation will continue to do a non-blocking read until all the data can be copied and then allows the thread continue, thus blocking only the calling thread. At least that's what the source code tells me. Yea, I took a look at lib/libc_r/uthread/uthread_read.c too, but it didn't paint the whole picture for me. Specifically, I couldn't find the definition for the _thread_sys_read() function. It looks like the polling magic to which Jason Evans referred occurs in some interesting code in uthread_kern.c, though. Thanks, -brian -- Brian O'Shea [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Multithreaded server performance
On Mon, Apr 24, 2000 at 09:58:49PM -0500, Chris Costello wrote: On Monday, April 24, 2000, Brian O'Shea wrote: Yea, I took a look at lib/libc_r/uthread/uthread_read.c too, but it didn't paint the whole picture for me. Specifically, I couldn't find the definition for the _thread_sys_read() function. It looks like the polling magic to which Jason Evans referred occurs in some interesting code in uthread_kern.c, though. _thread_sys_read() is the real read(2) syscall. They're renamed to ``_thread_sys_SYSCALL()'' for the purpose of reimplementing them in a thread-friendly manner, as you see with read() there. Well that explains it, then! There is actually a note about this in the read(2) man page which was confusing me before, but now I understand what it is talking about: IMPLEMENTATION NOTES In the non-threaded library read() is implemented as the read syscall. In the threaded library, the read syscall is assembled to _thread_sys_read() and read() is implemented as a function which locks d for read, then calls _thread_sys_read(). If the call to _thread_sys_read() would block, a context switch is performed. Before re- turning, read() unlocks d. Thanks, -brian -- Brian O'Shea [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Multithreaded server performance
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. 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(). The hardware is probably going to be UP at first -- a fast Pentium III (733MHz?), an Intel 820 board, an Adaptec U2W SCSI controller, and a couple of U2W LVD SCA disks to go with it. The operating system has yet to be chosen. I have tried Solaris 7 on similar hardware, and it seems so much slower than FreeBSD -- and so bloody unresponsive when doing I/O that even NT seems faster. On the other hand, Solaris's threads implementation is supposedly better than anything else out there. I'm not even considering Linux -- or should I? Is it safe to use FreeBSD 4.0-S on a production server? So far I've had nothing but positive experience with it. Any advice will be much appreciated. Alex Keahan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Multithreaded server performance
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. 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. LinuxThreads will definitely bog down with so many threads because the kernel scheduler has to deal with so many clone()d processes. FreeBSD's libc_r does not use clone() or anything similar. Instead, it is a userland call conversion library that multiplexes threads in a single process. This style of threads library should perform well for the type of application you are dealing with. Note that there is also ports/devel/linuxthreads, which is based on rfork(), which can be made to behave like Linux's clone(). Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
