From: Stefan Fritsch Date: Sun, 3 Jul 2011 19:55:35 +0000 (+0000) Subject: Add some docs for AsyncRequestWorkerFactor X-Git-Tag: 2.3.14^2~83 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=e66fbe276513655312f570aa3d495f6747f86adc;p=thirdparty%2Fapache%2Fhttpd.git Add some docs for AsyncRequestWorkerFactor git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1142490 13f79535-47bb-0310-9956-ffa450edef68 --- diff --git a/docs/manual/mod/event.xml b/docs/manual/mod/event.xml index 9d1a844e64e..e4f191c1a21 100644 --- a/docs/manual/mod/event.xml +++ b/docs/manual/mod/event.xml @@ -54,8 +54,16 @@ of consuming threads only for connections with active processing Apache HTTP Server traditionally keeps an entire child process/thread waiting for data from the client, which brings its own disadvantages. To solve this problem, this MPM uses a dedicated thread to handle both - the Listening sockets, and all sockets that are in a Keep Alive - state.

+ the Listening sockets, all sockets that are in a Keep Alive state, + and sockets where the handler and protocol filters have done their work + and the only remaining thing to do is send the data to the client. The + status page of mod_status shows how many connections are + in the mentioned states.

+ +

The improved connection handling does not yet work for certain + connection filters, in particular SSL. For SSL connections, this MPM will + fall back to the behaviour of the worker MPM and + reserve one worker thread per connection.

The MPM assumes that the underlying apr_pollset implementation is reasonably threadsafe. This enables the MPM to @@ -133,4 +141,55 @@ of consuming threads only for connections with active processing User + +AsyncRequestWorkerFactor +Limit concurrent connections per process +AsyncRequestWorkerFactor factor +2 +server config +Available in version 2.3.13 and later + + +

The event MPM handles some connections in an asynchronous way, where + request worker threads are only allocated for short periods of time as + needed, and other (mostly SSL) connections with one request worker thread + reserved per connection. This can lead to situations where all workers are + tied up and no worker thread is available to handle new work on established + async connetions.

+ +

To mitigate this problem, the event MPM does two things: Firstly, it + limits the number of connections accepted per process, depending on the + number of idle request workers. Secondly, if all workers are busy, it will + close connections in keep-alive state even if the keep-alive timeout has + not expired. This allows the respective clients to reconnect to a + different process which may still have worker threads available.

+ +

This directive can be used to fine-tune the per-process connection + limit. A process will only accept new connections if the current number of + connections is lower than:

+ +

+ ThreadsPerChild + + (AsyncRequestWorkerFactor * + number of idle workers) +

+ +

This means the absolute maximum numbers of concurrent connections is:

+ +

+ (AsyncRequestWorkerFactor + 1) * + MaxRequestWorkers +

+ +

MaxRequestWorkers was called + MaxClients prior to version 2.3.13. The above value + shows that the old name did not accurately describe its meaning for the event MPM.

+ +

AsyncRequestWorkerFactor can take non-integer + arguments, e.g "1.5".

+ + + + +