From a5f937e86a0e69e7436139b7f1c33ac4b1903c28 Mon Sep 17 00:00:00 2001 From: Luca Toscano Date: Fri, 19 Feb 2016 14:57:35 +0000 Subject: [PATCH] Documentation rebuild git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x@1731252 13f79535-47bb-0310-9956-ffa450edef68 --- docs/manual/mod/event.html.en | 72 ++++++++++++++++++++++++++++++----- docs/manual/sections.xml.fr | 2 +- docs/manual/sections.xml.ja | 2 +- docs/manual/sections.xml.ko | 2 +- docs/manual/sections.xml.meta | 4 +- docs/manual/sections.xml.tr | 2 +- 6 files changed, 69 insertions(+), 15 deletions(-) diff --git a/docs/manual/mod/event.html.en b/docs/manual/mod/event.html.en index af3402335d..9a12efc9c3 100644 --- a/docs/manual/mod/event.html.en +++ b/docs/manual/mod/event.html.en @@ -154,7 +154,7 @@ of the AsyncRequestWorkerFactor.

thread serving the response content can flush the first bytes until EWOULDBLOCK or EAGAIN is returned, delegating the rest to the listener. This one in turn waits for an event on the socket, and delegates the work to flush the rest of the content - to the first idle worker thread. Meanwhile in the latter example (FCGI/CGI/proxed content) + to the first idle worker thread. Meanwhile in the latter example (FCGI/CGI/proxied content) the MPM can't predict the end of the response and a worker thread has to finish its work before returning the control to the listener. The only alternative is to buffer the response in memory, but it wouldn't be the safest option for the sake of the @@ -231,15 +231,18 @@ of the AsyncRequestWorkerFactor.

no worker thread is available to handle new work on established async connections.

-

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.

+

To mitigate this problem, the event MPM does two things:

+

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 + limit. A process will only accept new connections if the current number of connections (not counting connections in the "closing" state) is lower than:

@@ -249,13 +252,64 @@ of the AsyncRequestWorkerFactor.

number of idle workers)

-

This means the absolute maximum numbers of concurrent connections is:

+

An estimation of the maximum concurrent connections across all the processes given + an average value of idle worker threads can be calculated with: +

+ + +

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

+ +

Example

+ 
ThreadsPerChild = 10
+ServerLimit = 4
+AsyncRequestWorkerFactor = 2
+MaxRequestWorkers = 40
+
+idle_workers = 4 (average for all the processes to keep it simple)
+
+max_connections = (ThreadsPerChild + (AsyncRequestWorkerFactor * idle_workers)) * ServerLimit 
+                = (10 + (2 * 4)) * 4 = 72
+ +
+ +

When all the worker threads are idle, then absolute maximum numbers of concurrent + connections can be calculared in a simpler way:

(AsyncRequestWorkerFactor + 1) * MaxRequestWorkers

+ +

Example

+ 
ThreadsPerChild = 10 
+ServerLimit = 4
+MaxRequestWorkers = 40
+AsyncRequestWorkerFactor = 2
+ + +

If all the processes have all threads idle then:

+ + 
idle_workers = 10
+ + +

We can calculate the absolute maximum numbers of concurrent connections in two ways:

+ + 
max_connections = (ThreadsPerChild + (AsyncRequestWorkerFactor * idle_workers)) * ServerLimit 
+                = (10 + (2 * 10)) * 4 = 120
+    
+max_connections = (AsyncRequestWorkerFactor + 1) * MaxRequestWorkers 
+                = (2 + 1) * 40 = 120
+ +
+ +

Tuning AsyncRequestWorkerFactor requires knowledge about the traffic handled by httpd in each specific use case, so changing the default value requires extensive testing and data gathering from mod_status.

+

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.

diff --git a/docs/manual/sections.xml.fr b/docs/manual/sections.xml.fr index d9ed9b91b3..fd0a5ff5b6 100644 --- a/docs/manual/sections.xml.fr +++ b/docs/manual/sections.xml.fr @@ -3,7 +3,7 @@ - + + + +