documentation rebuild

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1769878 13f79535-47bb-0310-9956-ffa450edef68

1 files changed, 45 insertions, 75 deletions

diff --git a/docs/manual/misc/perf-tuning.html.en b/docs/manual/misc/perf-tuning.html.en
index b6acb085e7..b2962cf3b2 100644
--- a/docs/manual/misc/perf-tuning.html.en
+++ b/docs/manual/misc/perf-tuning.html.en
@@ -30,21 +30,20 @@
 </div>
 
 
-    <p>Apache 2.x is a general-purpose webserver, designed to
+    <div class="warning"><h3>Warning</h3>
+      <p>This document is partially out of date and might be inaccurate.</p>
+    </div>
+
+    <p>Apache 2.4 is a general-purpose webserver, designed to
     provide a balance of flexibility, portability, and performance.
     Although it has not been designed specifically to set benchmark
-    records, Apache 2.x is capable of high performance in many
+    records, Apache 2.4 is capable of high performance in many
     real-world situations.</p>
 
-    <p>Compared to Apache 1.3, release 2.x contains many additional
-    optimizations to increase throughput and scalability. Most of
-    these improvements are enabled by default. However, there are
-    compile-time and run-time configuration choices that can
-    significantly affect performance. This document describes the
-    options that a server administrator can configure to tune the
-    performance of an Apache 2.x installation. Some of these
-    configuration options enable the httpd to better take advantage
-    of the capabilities of the hardware and OS, while others allow
+    <p>This document describes the options that a server administrator
+    can configure to tune the performance of an Apache 2.4 installation.
+    Some of these configuration options enable the httpd to better take
+    advantage of the capabilities of the hardware and OS, while others allow
     the administrator to trade functionality for speed.</p>
 
   </div>
@@ -94,7 +93,7 @@
         needed to enable it. (With Linux, for example, this means
         using Linux 2.4 or later. For early releases of Solaris 8,
         you may need to apply a patch.) On systems where it is
-        available, <code>sendfile</code> enables Apache 2 to deliver
+        available, <code>sendfile</code> enables Apache to deliver
         static content faster and with lower CPU utilization.</p>
       </li>
     </ul>
@@ -112,15 +111,12 @@
       
 
       <p>Prior to Apache 1.3, <code class="directive"><a href="../mod/core.html#hostnamelookups">HostnameLookups</a></code> defaulted to <code>On</code>.
-      This adds latency to every request because it requires a
-      DNS lookup to complete before the request is finished. In
-      Apache 1.3 this setting defaults to <code>Off</code>. If you need
-      to have addresses in your log files resolved to hostnames, use the
-      <code class="program"><a href="../programs/logresolve.html">logresolve</a></code>
-      program that comes with Apache, or one of the numerous log
-      reporting packages which are available.</p>
-
-      <p>It is recommended that you do this sort of postprocessing of
+      causing an extra latency penalty for every request due to a
+      DNS lookup to complete before the request was finished.
+      In Apache 2.4 this setting defaults to <code>Off</code>. If you need
+      to have addresses in your log files resolved to hostnames, please
+      consider post-processing rather than forcing Apache to do it in the first
+      place. It is recommended that you do this sort of post-processing of
       your log files on some machine other than the production web
       server machine, in order that this activity not adversely affect
       server performance.</p>
@@ -130,8 +126,13 @@
       an IP address) then you will pay for
       two DNS lookups (a reverse, followed by a forward lookup
       to make sure that the reverse is not being spoofed). For best
-      performance, therefore, use IP addresses, rather than names, when
-      using these directives, if possible.</p>
+      performance, whenever it is possible, use IP addresses rather
+      than domain names.</p>
+
+      <div class="warning"><h3>Warning:</h3>
+      <p>Please use the <code class="directive"><a href="../mod/mod_authz_core.html#require">Require</a></code> directive with Apache 2.4;
+      more info in the related <a href="../upgrading.html">upgrading guide</a>.</p>
+      </div>
 
       <p>Note that it's possible to scope the directives, such as
       within a <code>&lt;Location "/server-status"&gt;</code> section.
@@ -139,8 +140,7 @@
       matching the criteria. Here's an example which disables lookups
       except for <code>.html</code> and <code>.cgi</code> files:</p>
 
-      <pre class="prettyprint lang-config">HostnameLookups off
-&lt;Files ~ "\.(html|cgi)$"&gt;
+      <pre class="prettyprint lang-config">&lt;Files ~ "\.(html|cgi)$"&gt;
   HostnameLookups on
 &lt;/Files&gt;</pre>
 
@@ -324,60 +324,30 @@
 
     
 
-    <h3><a name="process" id="process">Process Creation</a></h3>
+    <h3><a name="process" id="process">Recycle child processes</a></h3>
 
-      
+    
 
-      <p>Prior to Apache 1.3 the <code class="directive"><a href="../mod/prefork.html#minspareservers">MinSpareServers</a></code>, <code class="directive"><a href="../mod/prefork.html#maxspareservers">MaxSpareServers</a></code>, and <code class="directive"><a href="../mod/mpm_common.html#startservers">StartServers</a></code> settings all had drastic effects on
-      benchmark results. In particular, Apache required a "ramp-up"
-      period in order to reach a number of children sufficient to serve
-      the load being applied. After the initial spawning of
-      <code class="directive"><a href="../mod/mpm_common.html#startservers">StartServers</a></code> children,
-      only one child per second would be created to satisfy the
-      <code class="directive"><a href="../mod/prefork.html#minspareservers">MinSpareServers</a></code>
-      setting. So a server being accessed by 100 simultaneous
-      clients, using the default <code class="directive"><a href="../mod/mpm_common.html#startservers">StartServers</a></code> of <code>5</code> would take on
-      the order of 95 seconds to spawn enough children to handle
-      the load. This works fine in practice on real-life servers
-      because they aren't restarted frequently. But it does really
-      poorly on benchmarks which might only run for ten minutes.</p>
-
-      <p>The one-per-second rule was implemented in an effort to
-      avoid swamping the machine with the startup of new children. If
-      the machine is busy spawning children, it can't service
-      requests. But it has such a drastic effect on the perceived
-      performance of Apache that it had to be replaced. As of Apache
-      1.3, the code will relax the one-per-second rule. It will spawn
-      one, wait a second, then spawn two, wait a second, then spawn
-      four, and it will continue exponentially until it is spawning
-      32 children per second. It will stop whenever it satisfies the
-      <code class="directive"><a href="../mod/prefork.html#minspareservers">MinSpareServers</a></code>
-      setting.</p>
-
-      <p>This appears to be responsive enough that it's almost
-      unnecessary to twiddle the <code class="directive"><a href="../mod/prefork.html#minspareservers">MinSpareServers</a></code>, <code class="directive"><a href="../mod/prefork.html#maxspareservers">MaxSpareServers</a></code> and <code class="directive"><a href="../mod/mpm_common.html#startservers">StartServers</a></code> knobs. When more than 4 children are
-      spawned per second, a message will be emitted to the
-      <code class="directive"><a href="../mod/core.html#errorlog">ErrorLog</a></code>. If you
-      see a lot of these errors, then consider tuning these settings.
-      Use the <code class="module"><a href="../mod/mod_status.html">mod_status</a></code> output as a guide.</p>
-
-    <p>Related to process creation is process death induced by the
-    <code class="directive"><a href="../mod/mpm_common.html#maxconnectionsperchild">MaxConnectionsPerChild</a></code>
-    setting. By default this is <code>0</code>,
-    which means that there is no limit to the number of connections
-    handled per child. If your configuration currently has this set
-    to some very low number, such as <code>30</code>, you may want to bump this
-    up significantly. If you are running SunOS or an old version of
-    Solaris, limit this to <code>10000</code> or so because of memory leaks.</p>
-
-    <p>When keep-alives are in use, children will be kept busy
-    doing nothing waiting for more requests on the already open
+    <p><code class="directive"><a href="../mod/mpm_common.html#maxconnectionsperchild">MaxConnectionsPerChild</a></code>
+    limits the numbers of connections that a child process can handle during
+    its lifetime (by default set to <code>0</code> - unlimited). This affects all
+    the <a href="../mpm.html#defaults">MPMs</a>, even the ones using threads.
+    For example, each process created by the <code class="module"><a href="../mod/worker.html">worker</a></code> MPM spawns
+    multiple threads that will handle connections, but this does not influence
+    the overall count. It only means that the sum of requests handled by all the
+    threads spawned by a single process will be counted against the
+    <code class="directive"><a href="../mod/mpm_common.html#maxconnectionsperchild">MaxConnectionsPerChild</a></code> value.</p>
+
+    <p><code class="directive"><a href="../mod/mpm_common.html#maxconnectionsperchild">MaxConnectionsPerChild</a></code> should
+    not have any limit in the optimal use case, since there should not be any
+    reason to force a process kill other than software bugs causing memory leaks
+    or excessive CPU usage.</p>
+
+    <p>When keep-alives are in use, a process (or a thread spawned by a process)
+    will be kept busy doing nothing but waiting for more requests on the already open
     connection. The default <code class="directive"><a href="../mod/core.html#keepalivetimeout">KeepAliveTimeout</a></code> of <code>5</code>
     seconds attempts to minimize this effect. The tradeoff here is
-    between network bandwidth and server resources. In no event
-    should you raise this above about <code>60</code> seconds, as <a href="http://www.hpl.hp.com/techreports/Compaq-DEC/WRL-95-4.html">
-    most of the benefits are lost</a>.</p>
-
+    between network bandwidth and server resources.</p>
     
 
   </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>