httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luca Toscano <toscano.l...@gmail.com>
Subject Re: Questions about mod_event's documentation
Date Tue, 02 Feb 2016 17:01:30 GMT
Hi Rainer,

thank you 100 times for this email, it was really helpful! Comments inline:

2016-02-02 17:12 GMT+01:00 Rainer Jung <rainer.jung@kippdata.de>:
>
>
> The number of worker threads per process is constant during the lifetime
> from the process creation to its end. It is equals to ThreadsPerChild and
> the sole purpose of this configuration item.
>

This information is not completely trivial to establish simply reading the
documentation, even if all the information are there. Reading mod_worker's
doc can lead to think about this option, but there is always the space for
some doubts..


>
> AsyncRequestWorkerFactor  comes into the image, because in contrast to the
> traditional MPMs prefork, worker and winnt, event does not have a 1:1
> relation between worker threads and client connections. Event is designed
> to scale better than those in terms of connections. It should handle a lot
> more connections with the same number of threads. How can this work? It
> works by freeing the worker threads from the connection handling in certain
> situations where the thread would actually simply wait until it can write
> back the next part of the response or until the next request on the same
> connection arrives. But this design results in some over commitment. What
> happens if by bad luck over time we accepted lots of connections, which
> were mostly idle and then suddenly many of them start activity which needs
> a worker thread for each of them. Then it might happen, that we do not have
> enough worker threads in the process that accepted the connections. We
> don't have a way to move such connections to another child process. Once
> the connection is accepted it stays with the same process.
>

The only thing that I would like to expand a bit would be: "in certain
situations where the thread would actually simply wait until it can write
back the next part of the response or until the next request on the same
connection arrives.", but as Eric told me on #httpd-dev it is a bit
complicate to summarise in few sentences (an easy one is keep alive). It
might not be needed in the documentation, but it would be good for the
people interested in an in depth look without reading the code.

The rest of the explanation is simply great, very easy and straightforward.
I would really like to add some of it to the how it works section because I
think it would help a lot of people.


> ...
>
> HTH a bit w.r.t. AsyncRequestWorkerFactor (and also hoping that I didn't
> make mistakes in explaining).
>
>
Same thing for the second part of the email, I believe that the directive
AsyncRequestWorkerFactor should get more information, maybe with a little
section explaining some directions to take for tuning it.

I want to re-state my point: httpd's documentation contains often all the
information needed but sometimes it misses the necessary background for the
people not heavily involved in the httpd community to get the whole picture
straight away.

I'll work on a small patch for the mod_event's documentation, and I'll send
it to the mailing list to get some feedback to get your opinion.

Thanks again!

Luca

Mime
View raw message