httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luca Toscano <>
Subject Questions about mod_event's documentation
Date Mon, 01 Feb 2016 09:17:44 GMT
Hi Apache Devs!

I am trying to understand if could use some
documentation improvements or if I am the only one not getting the whole
picture correctly.

I'd like to write a summary of my understanding of the module to get some

- mod_event reuses mod_worker's architecture using forking processes that
in turn create several threads (controlled using the ThreadPerChild
directive). A special thread for each process is called the listener (like
in worker) and it keeps track of the connections/sockets "assigned" to its

- mod_event's listener thread is smarter than its brother in mod_worker
since it keeps a list of sockets in: keep alive, flushing data to client
only (after the output chain has finished to process the response) and
complete new request/response to handle.

- when a socket changes its state, the listener checks free workers among
its thread pool and assign either some "small" work like handling keep
alives or flushing data, or a whole new request to handle.

- mod_ssl and mod_deflate are examples of filters that needs to act on the
whole response so a worker gets stuck flushing data to slow clients rather
than giving up the socket earlier to the listener and doing a different

- AsyncRequestWorkerFactor is used to regulate the amount of requests that
a single process/threads block can handle, calculating the value
periodically using the idle threads/workers available. In case of workers
maxed out, the keep alive sockets/connections are closed to free some space.

If my understanding is correct (I doubt it but let's assume this) then I
have the following questions:

- Would it be worth to add more info in the "how it works" section? A first
read may bring the user to think that the listening thread is the one doing
the actual work, rather than the workers, being a bit puzzled when reading
the AsyncRequestWorkerFactor section.

- Would it make sense to expand the summary to add more info about the fact
that most of worker's directives needs to be used? The "how it works"
section dominates and a reader is more keen to read it first and skip the
summary in my opinion.

- An interesting question has been filed a while ago in the comments: "This
documentation does not make it clear whether the event MPM at least allows
for keepalives on SSL connections to conserve a thread. Does it require the
use of a thread while transmitting only, or also while the kept-alive SSL
connection is idle?" - If my understanding is correct, the answer should be
that a slow client can still block a worker for a keep alive response due
to mod_ssl requirements, but that idle times are managed by the listener.

- The summary talks about "supporting threads" and given the fact that
is added to ThreadsPerChild, it raises the question about how many of them
are created at startup. Conversely, is it a way to say: the number of
threads for each process are ThreadsPerChild but since they now perform
also small bursts of work (like keep alive house keeping and flushing data
to clients) the total amount of connections allowed should be more to make
room for all these connection/socket states?

Apologies for the loooong email, hope that what I've written makes sense!
If not, I'll start reading again! :)


View raw message