Apache Performance Tuning Best Practices
Apache 2.0 is a general-purpose web server, designed to provide a balance of flexibility, portability, and performance. It is capable of high performance in many real-world situations.
There are few compile-time and run-time configuration choices that can significantly affect performance and could be recommended as best practices.
Operating system choice is largely a matter of local concerns. Below are the guidelines that have been very useful for obtaining good OS Performance:
Example
AllowOverrideall
For best performance use
Instead of using a wildcard such as: “
Also note that explicitly creating a
On some platforms, memory-mapping improves performance.
There are few scenarios where memory-mapping can hurt the performance or even the stability of the httpd:
(Note: This directive can be overridden on a per-directory basis.)
On most platforms, using sendfile improves performance by eliminating separate read and send mechanics.
There are cases where using sendfile can harm the stability of the httpd:
(Note: This directive can be overridden on a per-directory basis.)
If your configuration has this set to some very low number, you increase this up significantly.
If you are running SunOS or an old version of Solaris, limit this to
When keep-alives are in use, child would be kept busy doing nothing but waiting for more requests on the already open connection. The default
There are platform-specific MPMs for some platforms are:
The choice of MPM can affect the speed and scalability of the httpd:
If, on the other hand, you have modules statically linked into your Apache binary, you will need to recompile Apache in order to remove unwanted modules.
An associated question that arises here is, of course, what modules you need, and which ones you don’t. The answer here will, of course, vary from one web site to another. However, the minimal list of modules which you can get by with tends to include
For instance, consider the following example:
This would allow clients to walk through the entire filesystem.
Add the following to block your server’s configuration:
This will forbid default access to filesystem locations.
Add appropriate
For example,
Pay particular attention to the interactions of
The
If you are using Apache 1.3 or above, it is strongly recommend that the following line is included in your server configuration files:
There are few compile-time and run-time configuration choices that can significantly affect performance and could be recommended as best practices.
- Hardware and Operating System Issues ApacheBest Practises
- Run-Time Configuration Issues
- Compile-Time Configuration Issues
1.1 Hardware and Operating System Issues
The single biggest hardware issue affecting web server performance is RAM. A web server should never have to swap. Swapping increases latency of each request beyond a point that users consider “fast enough”. These cause users to stop and reload which further increase the load. The Maxclients setting should be controlled so that server does not spawn so many children that it starts swapping.Operating system choice is largely a matter of local concerns. Below are the guidelines that have been very useful for obtaining good OS Performance:
- Run the latest stable release and patch level of the operating system.
- If the OS supports sendfile
(2)system call, make sure you install the release and/or patches needed to enable it.Sendfileenables Apache 2 to deliver static content faster and with lower CPU utilization.
from domain or Deny from domain directives then you will pay for a double reverse DNS lookup. For best performance, use IP addresses, rather than names, when using these directives.1.1.1 AllowOverride
Wherever in your URL-space you allow overrides (typically.htaccess files) Apache will attempt to open .htaccess for each filename component.Example
DocumentRoot/www/htdocs <Directory/> AllowOverrideall
</Directory>For best performance use
AllowOverride None everywhere in your filesystem.1.1.2 Negotiation
Avoid content-negotiation for best performance of your web server. The benefits of negotiation outweigh the performance penalties. Use the option below to speed up the performance of the serverInstead of using a wildcard such as: “
DirectoryIndex index”, use a complete list of options: “DirectoryIndex index.cgi index.pl index.shtml index.html”Also note that explicitly creating a
type-map file provides better performance than usingMultiViews, as the necessary information can be determined by reading this single file, rather than having to scan the directory for files.1.1.3 Memory-mapping
In situations where Apache 2.0 needs to look at the contents of a file being delivered, it normally memory-maps the file if the OS supports some form ofmmap(2).On some platforms, memory-mapping improves performance.
There are few scenarios where memory-mapping can hurt the performance or even the stability of the httpd:
- On some operating systems,
mmapdoes not scale as well asread(2)when the number of CPUs increases. On multiprocessor Solaris servers, Apache 2.0 sometimes delivers server-parsed files faster whenmmapis disabled.
- If you memory-map a file located on an NFS-mounted filesystem and a process on another NFS client machine deletes or truncates the file, your process may get a bus error the next time it tries to access the mapped file content.
EnableMMAP off to disable the memory-mapping of delivered files.(Note: This directive can be overridden on a per-directory basis.)
1.1.4 Sendfile
In situations where Apache 2.0 can ignore the contents of the file to be delivered, it normally uses the kernel sendfile if the OS supports thesendfile(2) operation.On most platforms, using sendfile improves performance by eliminating separate read and send mechanics.
There are cases where using sendfile can harm the stability of the httpd:
- Some platforms may have broken sendfile support that the build system did not detect, especially if the binaries were built on another box and moved to such a machine with broken sendfile support.
- With an NFS-mounted files, the kernel may be unable to reliably serve the network file through its own cache.
EnableSendfile off to disable sendfile delivery of file contents.(Note: This directive can be overridden on a per-directory basis.)
1.1.5 Process Creation
Related to process creation is process death induced by theMaxRequestsPerChild setting. By default this is 0, which means that there is no limit to the number of requests handled per child.If your configuration has this set to some very low number, you increase this up significantly.
If you are running SunOS or an old version of Solaris, limit this to
10000, because of memory leaks.When keep-alives are in use, child would be kept busy doing nothing but waiting for more requests on the already open connection. The default
KeepAliveTimeout of 15 seconds attempts to minimize this effect. At any time you should not raise this option above 60 seconds, or else the benefits of this feature would be largely lost.1.1.6 Choosing an MPM
Apache 2.x supports pluggable concurrency models, called Multi-Processing Modules (MPMs). While building Apache, you have to choose a MPM.There are platform-specific MPMs for some platforms are:
beos, mpm_netware,mpmt_os2, and mpm_winnt.The choice of MPM can affect the speed and scalability of the httpd:
- The
workerMPM uses multiple child processes with many threads each. Each thread handles one connection at a time. Worker generally is a good choice for high-traffic servers because it has a smaller memory footprint than the prefork MPM.
- The
preforkMPM uses multiple child processes with one thread each. Each process handles one connection at a time. On many systems, prefork is comparable in speed to worker, but it uses more memory. Prefork’s thread less design has advantages over worker in some situations: it can be used with non-thread-safe third-party modules, and it is easier to debug on platforms with poor thread debugging support.
1.1.7 Modules
Since memory usage is such an important consideration in performance, you should attempt to eliminate modules that you’re not actually using. If you have built the modules as DSOs, eliminating modules is a simple matter of commenting out the associatedLoadModule directive for that module. This allows you to experiment with removing modules, and seeing if your site still functions in their absence.If, on the other hand, you have modules statically linked into your Apache binary, you will need to recompile Apache in order to remove unwanted modules.
An associated question that arises here is, of course, what modules you need, and which ones you don’t. The answer here will, of course, vary from one web site to another. However, the minimal list of modules which you can get by with tends to include
mod_mime, mod_dir, andmod_log_config. mod_log_config is, of course, optional, as you can run a web site without log files. This is, however, not recommended1.1.8 DYNAMIC_MODULE_LIMIT
If you have no intention of using dynamically loaded modules (you probably don’t if you’re reading this and tuning your server for every last ounce of performance) then you should add-DDYNAMIC_MODULE_LIMIT=0 when building your server. This will save RAM that’s allocated only for supporting dynamically loaded modules.1.2 Protect Server Files by Default
One aspect of Apache which is occasionally misunderstood is the feature of default access.For instance, consider the following example:
# cd /; ln -s / public_html Accessing http://localhost/~root/This would allow clients to walk through the entire filesystem.
Add the following to block your server’s configuration:
<Directory /> Order Deny,Allow Deny from all </Directory>This will forbid default access to filesystem locations.
Add appropriate
Directory blocks to allow access only to those locations you wish to give access.For example,
<Directory /usr/users/*/public_html> Order Deny,Allow Allow from all </Directory> <Directory /usr/local/httpd> Order Deny,Allow Allow from all </Directory>Pay particular attention to the interactions of
Location and Directory directives.The
UserDir directive should be handled carefully. Setting this directive to “./” would have the similar effect, for root, to as that in the example given above.If you are using Apache 1.3 or above, it is strongly recommend that the following line is included in your server configuration files:
UserDir disabled rootApache Installation In Solaris| How To Install Apache In Solaris
Download the source file of apache installing in solaris , it will be .gz extension.
Now let’s uncompress that archive using gunzip and tar. You should replace the httpd-
2.0.36.tar.gz below with the name of the gzip’d file you downloaded.
gunzip < httpd-2.0.36.tar.gz | tar xvf –
You should end up with an httpd-2.0.x directory, x being the particular sub-version of Apache you downloaded. Move into the newly created directory.
cd httpd-2.0.x
Now we’ll use the the configure and make commands to configure, make, and install Apache.
$ ./configure
The above command makes the shell run the script named ‘ configure ‘ which exists in the current directory. The configure script basically consists of many lines which are used to check some details about the machine on which the software is going to be installed. This script checks for lots of dependencies on your system. For the particular software to work properly, it may be requiring a lot of things to be existing on your machine already. When you run the configure script you would see a lot of output on the screen , each being some sort of question and a respective yes/no as the reply. If any of the major requirements are missing on your system, the configure script would exit and you cannot proceed with the installation, until you get those required things.
The main job of the configure script is to create a ‘ Makefile ‘ .
$ make
‘ make ‘ is actually a utility which exists on almost all Unix systems. For make utility to work it requires a file named Makefile in the same directory in which you run make. The configure script’s main job was to create a file named Makefile to be used with make utility. (Sometimes the Makefile is named as makefile also)
make would use the directions present in the Makefile and proceed with the installation. The Makefile indicates the sequence, that Linux must follow to build various components / sub-programs of your software. The sequence depends on the way the software is designed as well as many other factors.
The Makefile actually has a lot of labels (sort of names for different sections). Hence depending on what needs to be done the control would be passed to the different sections within the Makefile Or it is possible that at the end of one of the section there is a command to go to some next section.
Basically the make utility compiles all your program code and creates the executables. For particular section of the program to complete might require some other part of the code already ready, this is what the Makefile does. It sets the sequence for the events so that your program does not complain about missing dependencies.
One of the labels present in the Makefile happens to be named ‘ install ‘ .
If make ran successfully then you are almost done with the installation. Only the last step remains which is
$ make install
As indicated before make uses the file named Makefile in the same directory. When you run make without any parameters, the instruction in the Makefile begin executing from the start and as per the rules defined within the Makefile (particular sections of the code may execute after one another..thats why labels are used..to jump from one section to another). But when you run make with install as the parameter, the make utility searches for a label named install within the Makefile, and executes only that section of the Makefile.
The install section happens to be only a part where the executables and other required files created during the last step (i.e. make) are copied into the required final directories on your machine. E.g. the executable that the user runs may be copied to the /usr/local/bin so that all users are able to run the software. Similarly all the other files are also copied to the standard directories in Linux. Remember that when you ran make, all the executables were created in the temporary directory where you had unzipped your original tarball. So when you run make install, these executables are copied to the final directories.
$./configure –prefix=/apache_home_path
Your screen should look something like:
$ ./configure –PREFIX==/root/apache2
checking for chosen layout… Apache
checking for working mkdir -p… yes
checking build system type… i686-pc-linux-gnu
checking host system type… i686-pc-linux-gnu
checking target system type… i686-pc-linux-gnu
Configuring Apache Portable Runtime library …
config.status: executing default commands
Unless errors were reported (not warnings), your Apache installation is now configured and we can move on.
Making Apache produces screen full of Output. Your screen should look something like:
$ make
Making all in srclib
make[1]: Entering directory `/home/ryan/dl/apache_guide/httpd-
2.0.36/srclib’
Making all in apr
make[2]: Entering directory `/home/ryan/dl/apache_guide/httpd-
2.0.36/srclib/apr’
…
make[1]: Leaving directory `/home
Finally, you’re ready to install your Apache build.
$ make install
Now Apache is installed.
Testing Apache:
Go to apache home directory , for example if your apache_home is /root/apache2/
$ cd /root/apache2/bin
To check the syntax of your httpd.conf use the below command..
$ ./apachectl –t
If syntax is ok , the output would be “ Syntax is OK”.
Now start the apache instance using below command..
$ ./apachectl –k start
Test using http://hostip:port/
Output would be “ It Works”.
Now let’s uncompress that archive using gunzip and tar. You should replace the httpd-
2.0.36.tar.gz below with the name of the gzip’d file you downloaded.
gunzip < httpd-2.0.36.tar.gz | tar xvf –
You should end up with an httpd-2.0.x directory, x being the particular sub-version of Apache you downloaded. Move into the newly created directory.
cd httpd-2.0.x
Now we’ll use the the configure and make commands to configure, make, and install Apache.
$ ./configure
The above command makes the shell run the script named ‘ configure ‘ which exists in the current directory. The configure script basically consists of many lines which are used to check some details about the machine on which the software is going to be installed. This script checks for lots of dependencies on your system. For the particular software to work properly, it may be requiring a lot of things to be existing on your machine already. When you run the configure script you would see a lot of output on the screen , each being some sort of question and a respective yes/no as the reply. If any of the major requirements are missing on your system, the configure script would exit and you cannot proceed with the installation, until you get those required things.
The main job of the configure script is to create a ‘ Makefile ‘ .
$ make
‘ make ‘ is actually a utility which exists on almost all Unix systems. For make utility to work it requires a file named Makefile in the same directory in which you run make. The configure script’s main job was to create a file named Makefile to be used with make utility. (Sometimes the Makefile is named as makefile also)
make would use the directions present in the Makefile and proceed with the installation. The Makefile indicates the sequence, that Linux must follow to build various components / sub-programs of your software. The sequence depends on the way the software is designed as well as many other factors.
The Makefile actually has a lot of labels (sort of names for different sections). Hence depending on what needs to be done the control would be passed to the different sections within the Makefile Or it is possible that at the end of one of the section there is a command to go to some next section.
Basically the make utility compiles all your program code and creates the executables. For particular section of the program to complete might require some other part of the code already ready, this is what the Makefile does. It sets the sequence for the events so that your program does not complain about missing dependencies.
One of the labels present in the Makefile happens to be named ‘ install ‘ .
If make ran successfully then you are almost done with the installation. Only the last step remains which is
$ make install
As indicated before make uses the file named Makefile in the same directory. When you run make without any parameters, the instruction in the Makefile begin executing from the start and as per the rules defined within the Makefile (particular sections of the code may execute after one another..thats why labels are used..to jump from one section to another). But when you run make with install as the parameter, the make utility searches for a label named install within the Makefile, and executes only that section of the Makefile.
The install section happens to be only a part where the executables and other required files created during the last step (i.e. make) are copied into the required final directories on your machine. E.g. the executable that the user runs may be copied to the /usr/local/bin so that all users are able to run the software. Similarly all the other files are also copied to the standard directories in Linux. Remember that when you ran make, all the executables were created in the temporary directory where you had unzipped your original tarball. So when you run make install, these executables are copied to the final directories.
$./configure –prefix=/apache_home_path
Your screen should look something like:
$ ./configure –PREFIX==/root/apache2
checking for chosen layout… Apache
checking for working mkdir -p… yes
checking build system type… i686-pc-linux-gnu
checking host system type… i686-pc-linux-gnu
checking target system type… i686-pc-linux-gnu
Configuring Apache Portable Runtime library …
config.status: executing default commands
Unless errors were reported (not warnings), your Apache installation is now configured and we can move on.
Making Apache produces screen full of Output. Your screen should look something like:
$ make
Making all in srclib
make[1]: Entering directory `/home/ryan/dl/apache_guide/httpd-
2.0.36/srclib’
Making all in apr
make[2]: Entering directory `/home/ryan/dl/apache_guide/httpd-
2.0.36/srclib/apr’
…
make[1]: Leaving directory `/home
Finally, you’re ready to install your Apache build.
$ make install
Now Apache is installed.
Testing Apache:
Go to apache home directory , for example if your apache_home is /root/apache2/
$ cd /root/apache2/bin
To check the syntax of your httpd.conf use the below command..
$ ./apachectl –t
If syntax is ok , the output would be “ Syntax is OK”.
Now start the apache instance using below command..
$ ./apachectl –k start
Test using http://hostip:port/
Output would be “ It Works”.
Apache access log format| Log Format of Apache
LogFormat “%h %l %u %t \”%r\” %>s %b \”%{Referer}i\” \”%{User-agent}i\”" combined
http://httpd.apache.org/docs/2.2/logs.html
- %h is the remote host (ie the client IP)
- %l is the identity of the user determined by identd (not usually used since not reliable)
- %u is the user name determined by HTTP authentication
- %t is the time the server finished processing the request.
- %r is the request line from the client. (“GET / HTTP/1.0″)
- %>s is the status code sent from the server to the client (200, 404 etc.)
- %b is the size of the response to the client (in bytes)
- Referer is the page that linked to this URL.
- User-agent is the browser identification string.
http://httpd.apache.org/docs/2.2/logs.html
Subscribe to:
Posts (Atom)