From: Luca Toscano
Date: Fri, 2 Dec 2016 19:21:27 +0000 (+0000)
Subject: Fixed some wording in mpm-event's doc page
X-Git-Tag: 2.5.0-alpha~961
X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=c088ab304349fedf4122a64039590be36063327f;p=apache
Fixed some wording in mpm-event's doc page
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1772399 13f79535-47bb-0310-9956-ffa450edef68
---
diff --git a/docs/manual/mod/event.xml b/docs/manual/mod/event.xml
index 33fb808ae2..f7cca7b59c 100644
--- a/docs/manual/mod/event.xml
+++ b/docs/manual/mod/event.xml
@@ -112,7 +112,7 @@ of the AsyncRequestWorkerFactor.
and also the number of allowed processes
(MaxRequestWorkers
/ ThreadsPerChild), 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 MaxRequestWorkers,
@@ -120,17 +120,24 @@ of the AsyncRequestWorkerFactor.
but that are queued instead (up to the limit imposed by
ListenBacklog). 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:
+ or connections with keep-alive enabled). Two scenarios are very common:
- - Httpd graceful restart.
+ - During a graceful restart.
+ 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.
+
- When the server load goes down in a way that causes httpd to
stop some processes (for example due to
MaxSpareThreads).
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.
From 2.4.24 onward, mpm-event is smarter and it is able to handle