Tuning Your Apache Server

Updated by Elle Krout

Contribute on GitHub

View Project | View File | Edit File

Apache configuration has a major affect on your Linode’s performance. The easiest way to increase server performance is to turn off unneeded modules. This guide covers Apache modules, information on which modules to turn off, and other Apache performance tuning options.

The steps in this guide require root privileges. Be sure to run the steps below as root or with the sudo prefix. For more information on privileges see our Users and Groups guide.

Tools

There are a variety of tools that can assist in determining if you need to alter resource settings, including the top command and the load-testing program Siege. Linode’s own Longview service can also help in server monitoring. At minimum, familiarize yourself with the RAM and CPU usage of your server. Discover usage statistics with these commands:

1
2
echo [PID]  [MEM]  [PATH] &&  ps aux | awk '{print $2, $4, $11}' | sort -k2rn | head -n 20
ps -eo pcpu,pid,user,args | sort -k 1 -r | head -20

More specific resources for resource tuning Apache includes Apache mod_status and Apache2Buddy.

Apache mod_status

Apache mod_status diplays information related to incoming server connections by generating a detailed status page. View an example of this page at Apache’s own website.

  1. Open your website’s configuration file. This file is located at /etc/apache2/sites-available/example.com.conf on Debian/Ubuntu systems or /etc/httpd/conf.d/vhost.conf on CentOS/Fedora systems.

  2. Add the following to the <virtual_hosts> block:

    /etc/apache2/sites-available/example.com.conf (Debian/Ubuntu)
    /etc/httpd/conf.d/vhost.conf (CentOS/Fedora)
    1
    2
    3
    4
    5
    6
    <Location /server-status>
      SetHandler server-status
      Order Deny,Allow
      Deny from all
      Allow from localhost
    </Location>
    
  3. Apache mod_status also offers an option called ExtendedStatus, which provides additional information about each request made to Apache. To enable ExtendedStatus edit your Apache configuration file:

    /etc/apache2/apache2.conf (Debian/Ubuntu)
    /etc/httpd/confd/httpd.conf (CentOS/Fedora)
    1
    ExtendedStatus On
    

    Enabling ExtendedStatus consumes additional system resources.

  4. Restart Apache:

    • Debian/Ubuntu:

      1
      service apache2 restart
      
    • CentOS/Fedora:

      1
      /bin/systemctl reload httpd.service
      
  5. To view the file generated, download Lynx:

    • Debian/Ubuntu:

      1
      apt-get install lynx
      
    • Fedora/CentOS:

      1
      yum install lynx
      
  6. Open the file:

    1
    lynx http://localhost/server-status
    

Apache2Buddy

The Apache2Buddy script, similar to MySQLTuner, reviews your Apache setup, and makes suggestions based on your Apache process memory and overall RAM. Although it is a fairly basic program, focusing on the MaxClients directive, Apache2Buddy is useful, and can be run through a single command:

1
curl -L http://apache2buddy.pl/ | perl

Multi Processing Modules

Before making any changes to your Apache configuration, be sure to back up the configuration file:

On Debian/Ubuntu:

1
cp /etc/apache2/apache2.config ~/apache2.conf.backup

On CentOS/Fedora:

1
cp /etc/httpd/conf/httpd.config ~/httpd.conf.backup

Apache offers two Multi Processing Modules, three if on Apache 2.4, for managing your settings.

Each module creates child processes, differing primarily in how they handle threads.

Prefork

The prefork module creates a number of child processes at launch, each child handles only one thread. Since these processes deal solely with one thread at a time, making request speed suffer should there be too many concurrent requests. Should this occur, some requests essentially have to wait in line to be acted upon. To handle this, increase the number of child processes spawned, but be aware that this increases the amount of RAM being used. Prefork is the safest module, and should be used when using mods that are not thread safe.

Worker

The worker module’s child processes spawn many threads per process, each thread ready to take on new requests. This allows for a greater number of concurrent requests to come in, and in turn is easier on the server’s RAM usage. Overall, the worker module offers higher performance, but is less secure than prefork and cannot be used with modules that are not thread safe.

Event

The event module is only available on Apache 2.4 and is based off the worker MPM. Like the worker, it creates multiple threads per child process, with a thread dedicated to KeepAlive connections that are handed down to child threads once the request has been made. This is good for multiple concurrent connections, especially those that are not all active at the same time but make the occasional request. The event MPM functions the same as worker in the event of SSL connections.

Module Values

Once you select your MPM, you will need to change the values inside the configuration. These settings are located in the /etc/apache2/apache2.conf file on Debian/Ubuntu, and the /etc/httpd/conf/httpd.conf file on CentOS/Fedora. The MPM looks like this:

/etc/apache2/apache2.conf (Debian/Ubuntu)
/etc/httpd/conf/httpd.conf (CentOS/Fedora)
1
2
3
4
5
6
7
<IfModule mpm_prefork_module>
	StartServers          4
	MinSpareServers       20
	MaxSpareServers      40
	MaxClients           200
	MaxRequestsPerChild  4500
</IfModule>

For other MPMs replace <IfModule mpm_prefork_module> with <IfModule mpm_worker_module> or <IfModule mpm_event_module> for worker and event, respectively.

The next step to reconfiguring your Apache server is altering the above settings. To do this, you need to be aware of what each value does, and how best to change it.

Again, the best way to make configuration changes is to make incremental changes and then monitor the effects.

After making alterations to the Apache configuration, restart the service using service apache restart on Debian/Ubuntu or /bin/systemctl reload httpd.service on CentOS/Fedora.

StartServers

The StartServers value indicates the number of child processes created at startup, and is dynamically controlled depending on load. There is often little reason to alter this number, unless your server is restarted frequently and contains a large number of requests upon reboot.

MinSpareServers

Sets the minimum number of idle child processes. If there are fewer processes than the MinSpareServer number, more processes are created at the rate of one per second on Apache 2.2 or lower. With Apache 2.4, this rate increases exponentially starting with 1 and ending with 32 children spawned per second. The benefit of this value is that when a request comes in it can take an idle thread; should a thread not be available, Apache would have to spawn a new child, taking up resources and extending the time it takes for the request to go through. Note, too many idle processes would also have an adverse effect on the server.

MaxSpareServers

Sets the maximum number of idle child processes. If there are more idle processes than this number, then they are terminated. Unless your website is extremely busy, this number should not be set too high, since even idle processes consume resources.

MaxClients

The maximum amount of requests that can be served simultaneously, with any number going past the limit being queued. If this is set too low, connections sent to queue eventually time-out; however, if set too high, it causes the memory to start swapping. If this value is increased past 256, the ServerLimit value must also be increased.

One way to calculate the best value for this is to divide the amount of RAM each Apache process uses by the amount of RAM available, leaving some room for other processes. Use ApacheBuddy to help determine these values, or the commands below.

To determine the RAM each Apache process uses, replace httpd with apache2 on Debian or Ubuntu systems:

1
ps -ylC httpd --sort:rss

Divide the number by 2048 for megabytes.

To get information on memory usage:

1
free -m

To receive a fuller view of the resources Apache is using, use the top command.

MaxRequestsPerChild

This limits the number of requests a child server handles during its life. Once the limit has been hit, the child server dies. If set to 0, the child servers are set to never expire. The suggested value for this is a few thousand, to prevent memory leakage. Be aware that setting this too low can slow down the system, since creating new processes does take up resources.

ServerLimit

If you need to increase the MaxClients above 256, then increase your ServerLimit to match. To do this, add the ServerLimit line to your MPM code and alter the value:

1
ServerLimit          256

KeepAlive

The KeepAlive directive, when set to on allows for multiple requests to come from the same TCP connection. When a KeepAlive connection is used, it counts as only one request against the MaxRequestsPerChild directive. This value is kept outside of your MPM, but can tie in closely to your MPM choices.

More Information

You may wish to consult the following resources for additional information on this topic. While these are provided in the hope that they will be useful, please note that we cannot vouch for the accuracy or timeliness of externally hosted materials.

This guide is published under a CC BY-ND 4.0 license.