From: Igor S. <oz...@gr...> - 2000-08-25 19:59:16
|
Doug has a point on the use of prethreaded server rather than creating a thread on per connection basis. And I have thought that option myself. If you have a web site with millions of requests a day, prethreaded server is definately necessary. However, we are not going to have NEARLY as many connections as that. If we had 100,000 clients distributed, which may be enough to index the whole internet every single day, and each one of them connected every day with the server -> we would have 100,000 connections, which will take up a minute or two in CPU time per day for thread creation/destruction (on an average PC). Creating a new thread is faster than fork()ing almost in order of 100 times. I abandoned the idea of doing a preforked/prethreaded server because it does not provide real benefits, and it seemed more complicated to create. Plus doing a thread-per-connection server may perform with almost identical results as prethreaded server (see below). Here is some testing data on the performance that I have taken out of a Networking book, on performance of various types of web servers, in seconds of CPU time (this is for 5000 connections requesting 4000 bytes from the server): Solaris DUnix =============================================== ======= ====== Concurrent server, create one thread per client request...................... 18.7 4.7 Prethreaded with mutex locking to protect accept()............................ 8.6 3.5 Prethreaded with main thread calling accept().. 14.5 5.0 Concurrent server, one fork per client request. 504.2 168.9 Give me more feedback on this. Cheers, igor. -------------------------------------------------------------- Igor Stojanovski Grub.Org Inc. Chief Technical Officer 5100 N. Brookline #830 Oklahoma City, OK 73112 oz...@gr... Voice: (405) 917-9894 http://www.grub.org Fax: (405) 848-5477 -------------------------------------------------------------- |