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

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. Digitalberg’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:

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

Apache mod_status

Apache mod_status displays 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 
      on Debian/Ubuntu systems : /etc/apache2/sites-available/example.com.conf
      on CentOS/Fedora systems. /etc/httpd/conf.d/vhost.conf
      1. Add the following to the block: File excerpt:  /etc/apache2/sites-available/example.com.conf (Debian/Ubuntu)
        /etc/httpd/conf.d/vhost.conf (CentOS/Fedora)
<Location /server-status>
  SetHandler server-status
  Order Deny,Allow
  Deny from all
  Allow from localhost
</Location>
    1. 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)
ExtendedStatus On

Note: Enabling ExtendedStatus consumes additional system resources.

      1. Restart Apache:
            • Debian/Ubuntu:  service apache2 restart
            • CentOS/Fedora: /bin/systemctl reload httpd.service
      1. To view the file generated, download Lynx:

Debian/Ubuntu:

apt-get install lynx

Fedora/CentOS:

yum install lynx
      • Open the file:
lynx http://localhost/server-status

ApacheBuddy

The ApacheBuddy 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, ApacheBuddy is useful, and can be run through a single command:

curl http://cloudfiles.fanatassist.com/apachebuddy.pl | perl

Multi Processing Modules

Note: Before making any changes to your Apache configuration, be sure to backup the configuration file:

On Debian/Ubuntu:
cp /etc/apache2/apache2.config ~/apache2.conf.backup

On CentOS/Fedora:
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:

File excerpt: /etc/apache2/apache2.conf (Debian/Ubuntu)

File excerpt: /etc/httpd/conf/httpd.conf (CentOS/Fedora)

  StartServers          2
  MinSpareServers       6
  MaxSpareServers      12
  MaxClients           60
  MaxRequestsPerChild  3000

For other MPMs replace with or 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.

Note: 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:

ps -ylC httpd --sort:rss

Divide the number by 1024 for megabytes.

To get information on memory usage:

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 percent of 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 SeverLimit to match. To do this, add the SeverLimit line to your MPM code and alter the value:

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 please click here: Apache Performance Tuning