From 1a3860497a79a7dd6cce74c0bbaf37a2851ae6e5 Mon Sep 17 00:00:00 2001 From: Luca Toscano Date: Tue, 15 Nov 2016 20:42:35 +0000 Subject: [PATCH] Updated the perf-tuning documentation Removed some out of date references and re-wrote some sections. Added also a banner at the top of the page to warn the users about stale content. The next step is to improve the accept() related documentation introducing the latest changes made for event (and how awesome event is). git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1769877 13f79535-47bb-0310-9956-ffa450edef68 --- docs/manual/misc/perf-tuning.xml | 127 +++++++++++-------------------- 1 file changed, 45 insertions(+), 82 deletions(-) diff --git a/docs/manual/misc/perf-tuning.xml b/docs/manual/misc/perf-tuning.xml index 0b87007cac..66837517cd 100644 --- a/docs/manual/misc/perf-tuning.xml +++ b/docs/manual/misc/perf-tuning.xml @@ -27,21 +27,20 @@ -

Apache 2.x is a general-purpose webserver, designed to + Warning +

This document is partially out of date and might be inaccurate.

+ + +

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.

-

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 +

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.

 @@ -86,7 +85,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, sendfile enables Apache 2 to deliver + available, sendfile enables Apache to deliver static content faster and with lower CPU utilization.

@@ -123,15 +122,12 @@

Prior to Apache 1.3, HostnameLookups defaulted to On. - 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 Off. If you need - to have addresses in your log files resolved to hostnames, use the - logresolve - program that comes with Apache, or one of the numerous log - reporting packages which are available.

- -

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 Off. 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.

@@ -143,8 +139,14 @@ 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.

+ performance, whenever it is possible, use IP addresses rather + than domain names.

+ + Warning: +

Please use the Require directive with Apache 2.4; + more info in the related upgrading guide.

+

Note that it's possible to scope the directives, such as within a <Location "/server-status"> section. @@ -153,7 +155,6 @@ except for .html and .cgi files:

-HostnameLookups off <Files ~ "\.(html|cgi)$"> HostnameLookups on </Files> @@ -345,67 +346,29 @@ DirectoryIndex index.cgi index.pl index.shtml index.html
- Process Creation - -

Prior to Apache 1.3 the MinSpareServers, MaxSpareServers, and StartServers 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 - StartServers children, - only one child per second would be created to satisfy the - MinSpareServers - setting. So a server being accessed by 100 simultaneous - clients, using the default StartServers of 5 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.

- -

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 - MinSpareServers - setting.

- -

This appears to be responsive enough that it's almost - unnecessary to twiddle the MinSpareServers, MaxSpareServers and StartServers knobs. When more than 4 children are - spawned per second, a message will be emitted to the - ErrorLog. If you - see a lot of these errors, then consider tuning these settings. - Use the mod_status output as a guide.

- -

Related to process creation is process death induced by the - MaxConnectionsPerChild - setting. By default this is 0, - 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 30, you may want to bump this - up significantly. If you are running SunOS or an old version of - Solaris, limit this to 10000 or so because of memory leaks.

- -

When keep-alives are in use, children will be kept busy - doing nothing waiting for more requests on the already open + Recycle child processes + +

MaxConnectionsPerChild + limits the numbers of connections that a child process can handle during + its lifetime (by default set to 0 - unlimited). This affects all + the MPMs, even the ones using threads. + For example, each process created by the worker 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 + MaxConnectionsPerChild value.

+ +

MaxConnectionsPerChild 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.

+ +

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 KeepAliveTimeout of 5 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 60 seconds, as - most of the benefits are lost.

- + between network bandwidth and server resources.

-- 2.40.0