Hello!
I have added some <note>s to the AsyncRequestWorkerFactor directive's usage
section of mod_event but I am getting this error while running the build
validate.xml step:
./build.sh validate-xml
Buildfile: build.xml
validate-xml:
[xmlvalidate] $HOME/httpd-trunk/docs/manual/mod/event.xml:336:9: The
content of element type "usage" must match
"(p|example|note|table|ul|ol|dl|pre|highlight|blockquote)*".
BUILD FAILED
$HOME/httpd-trunk/docs/manual/style/lang-targets.xml:294:
$HOME/httpd-trunk/docs/manual/mod/event.xml is not a valid XML document.
I've attached the patch if anybody wants to take a look. Even if I've read
https://httpd.apache.org/docs-project/docsformat.html I am still a bit
confused about how to debug/fix these kind of things. I haven't found a
good way to check where these rules are defined in the xml files of the
style directory, can anybody give me an hint?
I've tried to remove two of the three <note> blocks and validate-xml works,
but I haven't figure out why (I am probably reading the allowed pattern in
the error message in the wrong way).
Thanks!
Luca
Index: mod/event.xml
===================================================================
--- mod/event.xml (revision 1729947)
+++ mod/event.xml (working copy)
@@ -116,7 +116,7 @@
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,12 +231,15 @@
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
@@ -249,13 +252,80 @@
<var>number of idle workers</var>)
</strong></p>
- <p>This means the absolute maximum numbers of concurrent connections
is:</p>
+ <note><title>Calculations related to connections handled by each
process</title>
+ <pre>
+max_connections = ThreadsPerChild + (AsyncRequestWorkerFactor * idle_workers)
+
+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
+
+max_idle_connections + busy_workers =
+ busy_workers + (AsyncRequestWorkerFactor + 1) * idle_workers
+
+max_idle_connections = (AsyncRequestWorkerFactor + 1) * idle_workers
+
+ </pre>
+ </note>
+
+ <p>The absolute maximum numbers of concurrent connections is:</p>
+
<p class="indent"><strong>
(<directive>AsyncRequestWorkerFactor</directive> + 1) *
<directive module="mpm_common">MaxRequestWorkers</directive>
</strong></p>
+ Math is always useful but sometimes confusing, some examples will surely
help to clarify doubts that might arise:
+
+ <note><title>Example 1</title>
+ <pre>
+
+ThreadsPerChild = 10
+ServerLimit = 4
+MaxRequestWorkers = 40
+AsyncRequestWorkerFactor = 2
+
+ </pre>
+
+ <p>If all the threads are idle for each process the idle_workers value is
10.</p>
+
+ <p>We can calculate the absolute maximum numbers of concurrent connections
in two ways:</p>
+
+ <pre>
+
+max_connections = (ThreadsPerChild + (AsyncRequestWorkerFactor *
idle_workers)) * ServerLimit
+ = (10 + (2 * 10)) * 4 = 120
+
+max_connections = (AsyncRequestWorkerFactor + 1) * MaxRequestWorkers
+ = (2 + 1) * 40 = 120
+
+ </pre>
+ </note>
+
+ <p>Of course the above example is only related to a theoretical maximum,
let's take a look to a more common use case:</p>
+
+ <note><title>Example 2</title>
+ <pre>
+
+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
+
+ </pre>
+ </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>
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscr...@httpd.apache.org
For additional commands, e-mail: docs-h...@httpd.apache.org
