httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pane <>
Subject Re: Bucket management strategies for async MPMs?
Date Wed, 04 Sep 2002 07:18:39 GMT
Paul J. Reder wrote:

> Brian Pane wrote:
>> I've been thinking about strategies for building a
>> multiple-connection-per-thread MPM for 2.0.  It's
>> conceptually easy to do this:
>>  * Start with worker.
>>  * Keep the model of one worker thread per request,
>>    so that blocking or CPU-intensive modules don't
>>    need to be rewritten as state machines.
>>  * In the core output filter, instead of doing
>>    actual socket writes, hand off the output
>>    brigades to a "writer thread."
> During a discusion today, the idea came up to have the
> code check if it could be written directly instead of
> always passing it to the writer. If the whole response
> is present and can be successfully written, why not save
> the overhead. If the write fails, or the response is too
> complex, then pass it over to the writer.

+1.  In cases where the entire file can be
delivered in one call to sendfile/sendfilev,
all we'll have to do in the writer thread is
close the connection once the write completes.

>>  * As soon as the worker thread has sent an EOS
>>    to the writer thread, let the worker thread
>>    move on to the next request.
> I have a small concern here. Right now the writes are
> providing the throttle that keeps the system from generating
> so much queued output that we burn system resources. If
> we allow workers to generate responses without a throttle,
> it seems possible that the writer's queue will grow to the
> point that the system starts running out of resources.

Right.  The solution I'd been thinking of is
a variant of the current worker's "queue_info"
struct: a central structure for process that
keeps a count of open connections.  The listener
thread increments this counter every time it does
an accept, and the writer thread decrements it
every time a connection completes.  If the count
reaches a configured maximum, the listener blocks
on a condition variable until the writer closes
at least one current connection and wakes up
the listener.


View raw message