On Tue, Nov 10, 2009 at 05:30:34PM -0500, Akins, Brian wrote: > On 11/10/09 1:56 PM, "Greg Stein" <[email protected]> wrote: > > > > But some buckets might be performing gzip or SSL encryption. That > > consumes CPU within the network thread. > > You could just run x times CPU cores number of "network" threads. You can't > use more than 100% of a CPU anyway. > > The model that some of us discussed -- Greg, you may have invented it ;) -- > was to have a small pool of acceptor threads (maybe just one) and a pool of > "worker" threads. The acceptor threads accept connections and move them into > worker threads - that's it. A single fd is then entirely owned by that > worker thread until it (the fd) goes away - network/disk io, gzip, ssl, etc. Sun Web Server (originated from Netscape) (Also Open Web Server) currently handle this way. It has a pool of acceptor threads which accepts connections, acceptor threads pushes the connection to a connection queue, worker threads pulls connection from connection queue and serves the request. Keep alive daemon is also multi-threaded. So multiple keep alive threads polls for the various sets of connection for future HTTP requests. The above architecture is highly scalable. Recently Sun published a specweb record using this Web Server for 128 CMT threads (32 cores system). http://www.spec.org/web2005/results/res2009q4/web2005-20091013-00143.txt
You can see the sources from Open Web Server code if you are interested. http://wikis.sun.com/display/wsFOSS/Open+Web+Server Regards, Basant.
