On Tue, Nov 10, 2009 at 17:30, Akins, Brian <[email protected]> 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.
One of those buckets might (ahem) block on a file read. While it is doing that, you want to pass control to another bucket. The buckets should be avoiding indetermine blocks like a socket or a pipe, we've basically stated that a file is okay. If we had async I/O, then we'd want to disallow that, too. Mutexes/semaphores can be used in a bucket, as long as they attempt to lock with "nowait" semantics. > 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. Those worker threads are what we have today. It means that you have a 1:1 mapping of client connections to threads. That places serious bounds on your scaling. I'd like to see a few "network" threads multiplexing all the writing to clients. Then you have "worker" threads parsing the request and assembling the response buckets. The resulting buckets might generate-as-they-go, so the worker thread will complete very quickly. Or the worker thread could build a response bucket that already has all of its data, taking a while to do so. It all depends upon the implementation of the buckets and their construction. Then take all of *that*, and spread it across several processes for solid uptime, with a master monitor process. Cheers, -g
