Added a couple of suggestions below.
On 4/29/2016 5:40 AM, elu...@apache.org wrote:
Author: elukey
Date: Fri Apr 29 12:40:49 2016
New Revision: 1741621
URL: http://svn.apache.org/viewvc?rev=1741621&view=rev
Log:
Added a specific reference to mpm-event's doc about the fact that mpm-accept is
not needed anymore
Modified:
httpd/httpd/trunk/docs/manual/mod/event.xml
Modified: httpd/httpd/trunk/docs/manual/mod/event.xml
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/event.xml?rev=1741621&r1=1741620&r2=1741621&view=diff
==============================================================================
--- httpd/httpd/trunk/docs/manual/mod/event.xml (original)
+++ httpd/httpd/trunk/docs/manual/mod/event.xml Fri Apr 29 12:40:49 2016
@@ -44,13 +44,13 @@ of consuming threads only for connection
<seealso><a href="worker.html">The worker MPM</a></seealso>
</section>
@@ -58,10 +58,10 @@ of the <directive>AsyncRequestWorkerFact
<section id="how-it-works"><title>How it Works</title>
<p>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
+ 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.
+ 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
along with a pool of worker threads, sharing queues specific for those
requests in keep-alive mode (or, more simply, "readable"), those in write-
@@ -70,7 +70,12 @@ of the <directive>AsyncRequestWorkerFact
adjusts these queues and pushes work to the worker pool.
</p>
- <p>The total amount of connections that a single process/threads block can handle is regulated
+ <p>This new architecture, leveraging non blocking sockets and modern kernel
"non" is not a word by itself. "non blocking" should be "non-blocking".
+ features exposed by <glossary>APR</glossary> (like Linux's epoll),
+ does not require anymore the <code>mpm_accept</code> <directive
module="core">Mutex</directive>
1) "mpm_accept" should be "mpm-accept".
2) The grammar in "does not require anymore the" seems a bit awkward.
An easier way to say this is "no longer requires the".
+ configured to avoid the thundering herd problem.</p>
+
+ <p>The total amount of connections that a single process/threads block can
handle is regulated
by the <directive>AsyncRequestWorkerFactor</directive> directive.</p>
<section id="async-connections"><title>Async connections</title>
