httpd-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From elu...@apache.org
Subject svn commit: r1731251 - /httpd/httpd/branches/2.4.x/docs/manual/mod/event.xml
Date Fri, 19 Feb 2016 14:57:06 GMT
Author: elukey
Date: Fri Feb 19 14:57:06 2016
New Revision: 1731251

URL: http://svn.apache.org/viewvc?rev=1731251&view=rev
Log:
Backporting mod_event's doc updates from trunk

Modified:
    httpd/httpd/branches/2.4.x/docs/manual/mod/event.xml

Modified: httpd/httpd/branches/2.4.x/docs/manual/mod/event.xml
URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/docs/manual/mod/event.xml?rev=1731251&r1=1731250&r2=1731251&view=diff
==============================================================================
--- httpd/httpd/branches/2.4.x/docs/manual/mod/event.xml (original)
+++ httpd/httpd/branches/2.4.x/docs/manual/mod/event.xml Fri Feb 19 14:57:06 2016
@@ -116,7 +116,7 @@ of the <directive>AsyncRequestWorkerFact
         thread serving the response content can flush the first bytes until <code>EWOULDBLOCK</code>
         or <code>EAGAIN</code> 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 <directive>AsyncRequestWorkerFact
     no worker thread is available to handle new work on established async
     connections.</p>
 
-    <p>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.</p>
+    <p>To mitigate this problem, the event MPM does two things:</p>
+    <ul>
+        <li>it limits the number of connections accepted per process, depending on
the
+            number of idle request workers;</li>
+        <li>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.</li>
+    </ul>
 
     <p>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 <strong>process</strong> will only accept new connections if the
current number of
     connections (not counting connections in the "closing" state) is lower
     than:</p>
 
@@ -249,13 +252,72 @@ of the <directive>AsyncRequestWorkerFact
         <var>number of idle workers</var>)
     </strong></p>
 
-    <p>This means the absolute maximum numbers of concurrent connections is:</p>
+    <p>An estimation of the maximum concurrent connections across all the processes
given
+        an average value of idle worker threads can be calculated with:
+    </p>
+
+
+    <p class="indent"><strong>
+        (<directive module="mpm_common">ThreadsPerChild</directive> +
+        (<directive>AsyncRequestWorkerFactor</directive> *
+        <var>number of idle workers</var>)) * 
+        <directive module="mpm_common">ServerLimit</directive>
+    </strong></p>
+
+    <note><title>Example</title>
+    <highlight language="config">
+
+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
+    
+    </highlight>
+    </note>
+
+    <p>When all the worker threads are idle, then absolute maximum numbers of concurrent

+        connections can be calculared in a simpler way:</p>
 
     <p class="indent"><strong>
         (<directive>AsyncRequestWorkerFactor</directive> + 1) *
         <directive module="mpm_common">MaxRequestWorkers</directive>
     </strong></p>
 
+
+    <note><title>Example</title>
+    <highlight language="config">
+    
+ThreadsPerChild = 10 
+ServerLimit = 4
+MaxRequestWorkers = 40
+AsyncRequestWorkerFactor = 2 
+    
+    </highlight>
+
+    <p>If all the processes have all threads idle then: </p>
+
+    <highlight language="config">idle_workers = 10</highlight>
+
+    <p>We can calculate the absolute maximum numbers of concurrent connections in two
ways:</p>
+    
+    <highlight language="config">
+    
+max_connections = (ThreadsPerChild + (AsyncRequestWorkerFactor * idle_workers)) * ServerLimit

+                = (10 + (2 * 10)) * 4 = 120
+    
+max_connections = (AsyncRequestWorkerFactor + 1) * MaxRequestWorkers 
+                = (2 + 1) * 40 = 120
+    
+    </highlight>
+    </note>
+
+    <p>Tuning <directive>AsyncRequestWorkerFactor</directive> 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 <module>mod_status</module>.</p>
+
     <p><directive module="mpm_common">MaxRequestWorkers</directive> was
called
     <directive>MaxClients</directive> prior to version 2.3.13. The above value
     shows that the old name did not accurately describe its meaning for the event MPM.</p>



Mime
View raw message