httpd-dev mailing list archives

On Tue, Nov 10, 2009 at 17:30, Akins, Brian <Brian.Akins@turner.com> wrote:
> On 11/10/09 1:56 PM, "Greg Stein" <gstein@gmail.com> 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