summaryrefslogtreecommitdiffstats
path: root/docs/manual/mod/event.html.en
diff options
context:
space:
mode:
authorLuca Toscano <elukey@apache.org>2016-12-02 20:21:51 +0100
committerLuca Toscano <elukey@apache.org>2016-12-02 20:21:51 +0100
commitbb4c17445bdef6e0e788d0e13a089020fc5de16e (patch)
tree2ad656be69ec120276546caf369e7166cafe8fd9 /docs/manual/mod/event.html.en
parentFixed some wording in mpm-event's doc page (diff)
downloadapache2-bb4c17445bdef6e0e788d0e13a089020fc5de16e.tar.xz
apache2-bb4c17445bdef6e0e788d0e13a089020fc5de16e.zip
mpm-event's doc rebuild
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1772400 13f79535-47bb-0310-9956-ffa450edef68
Diffstat (limited to '')
-rw-r--r--docs/manual/mod/event.html.en19
1 files changed, 13 insertions, 6 deletions
diff --git a/docs/manual/mod/event.html.en b/docs/manual/mod/event.html.en
index 7f61dd4b0d..ed35c97427 100644
--- a/docs/manual/mod/event.html.en
+++ b/docs/manual/mod/event.html.en
@@ -150,7 +150,7 @@ of the <code class="directive">AsyncRequestWorkerFactor</code>.</p>
and also the number of allowed processes
(<code class="directive"><a href="../mod/mpm_common.html#maxrequestworkers">MaxRequestWorkers</a></code>
/ <code class="directive"><a href="../mod/mpm_common.html#threadsperchild">ThreadsPerChild</a></code>), meanwhile
- the Scoreboad is a representation of all the running processes and
+ the Scoreboard is a representation of all the running processes and
the status of their worker threads. If the scoreboard is full (so all the
threads have a state that is not idle) but the number of active requests
served is not <code class="directive"><a href="../mod/mpm_common.html#maxrequestworkers">MaxRequestWorkers</a></code>,
@@ -158,17 +158,24 @@ of the <code class="directive">AsyncRequestWorkerFactor</code>.</p>
but that are queued instead (up to the limit imposed by
<code class="directive"><a href="../mod/mpm_common.html#listenbacklog">ListenBacklog</a></code>). Most of the times
the threads are stuck in the Graceful state, namely they are waiting to
- finish their work with a TCP connection to terminate and free a
+ finish their work with a TCP connection to safely terminate and free up a
scoreboard slot (for example handling long running requests, slow clients
- or a connection with keep-alive enabled). Two scenarios are very common:</p>
+ or connections with keep-alive enabled). Two scenarios are very common:</p>
<ul>
- <li>Httpd graceful restart.</li>
+ <li>During a <a href="../stopping.html#graceful">graceful restart</a>.
+ The parent process signals all its children to complete
+ their work and terminate, while it reloads the config and forks new
+ processes. If the old children keep running for a while before stopping,
+ the scoreboard will be partially occupied until their slots are freed.
+ </li>
<li>When the server load goes down in a way that causes httpd to
stop some processes (for example due to
<code class="directive"><a href="../mod/mpm_common.html#maxsparethreads">MaxSpareThreads</a></code>).
This is particularly problematic because when the load increases again,
- httpd will try to start more processes.
- If the pattern repeats, the number of processes can rise quite a bit.
+ httpd will try to start new processes.
+ If the pattern repeats, the number of processes can rise quite a bit,
+ ending up in a mixture of old processes trying to stop and new ones
+ trying to do some work.
</li>
</ul>
<p>From 2.4.24 onward, mpm-event is smarter and it is able to handle