httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Re: Httpd 3.0 or something else
Date Tue, 10 Nov 2009 23:20:41 GMT
On Tue, Nov 10, 2009 at 17:30, Akins, Brian <> wrote:
> On 11/10/09 1:56 PM, "Greg Stein" <> 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.


View raw message