httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Eissing <>
Subject Re: Questions about mod_event's documentation
Date Mon, 01 Feb 2016 09:54:37 GMT

thanks for the long mail. I am looking forward to read the answers to your questions, as I
have *assumptions* about them, but am myself not certain.

> Am 01.02.2016 um 10:17 schrieb Luca Toscano <>:
> 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 feedback:
> - 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 parent.
> - 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. 

My read: Not only in keepalive, but also in timeout, depending on the connection state.

> - 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. 

"changes its state" -> raises an event. If the event needs processing by a worker...

> - 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 work.

Hmm, not sure I understand your point. Every part in the process of generating the bytes sent
out on the socket is involved here. The crucial difference between the worker and the event
mpm is:
- worker keeps the response state on the stack
- event keeps the response state in the heap
which means that calls to response processing 
- on worker, need to return when all is done
- on event, may return whenever a READ/WRITE event or TIMEOUT/KEEPALIVE is needed. 

In that way, writing a response with event is "stutter stepping" it. Write until EWOULDBLOCK,
return, queued, event, write until EWOULDBLOCK,...

(my understanding)

> - 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
> - 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. 
There is some ongoing work done in trunk in regard to this...

> - The summary talks about "supporting threads" and given the fact that AsyncRequestWorkerFactor
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! :)
> Luca

View raw message