From: Luca Toscano Date: Tue, 16 Feb 2016 07:52:09 +0000 (+0000) Subject: Documentation rebuild X-Git-Tag: 2.5.0-alpha~2064 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=4711134a8b7d333ffcb58991d90a8a5892ea491b;p=thirdparty%2Fapache%2Fhttpd.git Documentation rebuild git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1730641 13f79535-47bb-0310-9956-ffa450edef68 --- diff --git a/docs/manual/mod/event.html.en b/docs/manual/mod/event.html.en index ed5778247c8..7ef14577b33 100644 --- a/docs/manual/mod/event.html.en +++ b/docs/manual/mod/event.html.en @@ -36,7 +36,8 @@ of consuming threads only for connections with active processing Source File:event.c

Summary

-

The event Multi-Processing Module (MPM) is +

The event Multi-Processing Module (MPM) is, + as its name implies, an asynchronous, event-based implementation designed to allow more requests to be served simultaneously by passing off some processing work to the listeners threads, freeing up the worker threads to serve new requests.

@@ -93,16 +94,18 @@ of the AsyncRequestWorkerFactor.

top

How it Works

-

This MPM tries to fix the 'keep alive problem' in HTTP. After a client +

This original goal of this MPM was to fix the 'keep alive problem' in HTTP. After a client completes the first request, it can keep the connection open, sending further requests using the same socket and saving significant overhead in creating TCP connections. However, 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 listener thread for each process - to handle both the Listening sockets, all sockets that are in a Keep Alive state, - sockets where the handler and protocol filters have done their work - and the ones where the only remaining thing to do is send the data to the client. + To solve this problem, this MPM uses a dedicated listener thread for each process + along with a pool of worker threads, sharing queues specific for those + requests in keep-alive mode (or, more simply, "readable"), those in write- + completion mode, and those in the process of shutting down ("closing"). + An event loop, triggered on the status of the socket's availability, + adjusts these queues and pushes work to the worker pool.

The total amount of connections that a single process/threads block can handle is regulated @@ -242,7 +245,7 @@ of the AsyncRequestWorkerFactor.

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:

@@ -252,24 +255,33 @@ of the AsyncRequestWorkerFactor.

number of idle workers)

-

Idle connections handled by each process

- 
max_connections = ThreadsPerChild + (AsyncRequestWorkerFactor * idle_workers)
+    
An estimation of the maximum concurrent connections across all the processes given
+        an average value of idle worker threads can be calculated with:
+    

 
-ThreadsPerChild = idle_workers + busy_workers
-            
-max_connections = (idle_workers + busy_workers) + (AsyncRequestWorkerFactor * idle_workers)
-                = busy_workers + (AsyncRequestWorkerFactor + 1) * idle_workers 
 
-max_connections = max_idle_connections + busy_workers 
+    

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

 
-max_idle_connections + busy_workers = 
-                busy_workers + (AsyncRequestWorkerFactor + 1) * idle_workers 
+    
Example

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

+max_connections = (ThreadsPerChild + (AsyncRequestWorkerFactor * idle_workers)) * ServerLimit 
+                = (10 + (2 * 4)) * 4 = 72
-

The absolute maximum numbers of concurrent connections is:

+

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

(AsyncRequestWorkerFactor + 1) * @@ -277,7 +289,7 @@ max_idle_connections = (AsyncRequestWorkerFactor + 1) * idle_workers

-

Example 1

+

Example

ThreadsPerChild = 10 
 ServerLimit = 4
 MaxRequestWorkers = 40
@@ -299,21 +311,6 @@ max_connections = (AsyncRequestWorkerFactor + 1) * MaxRequestWorkers
-

The above example is only related to a theoretical maximum, let's take a look to a more common use case:

- -

Example 2

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

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 diff --git a/docs/manual/mod/event.xml.fr b/docs/manual/mod/event.xml.fr index 71bf8f56cd8..3482aecfe8e 100644 --- a/docs/manual/mod/event.xml.fr +++ b/docs/manual/mod/event.xml.fr @@ -1,7 +1,7 @@ - +