Supercharging Apache

Originally released in 1995, the Apache web server is a true Internet old-timer. Of course it’s true that newer, more nimble open-source web servers have come along in the last twenty years—you’re probably familiar with Nginx—but Apache still operates on the lion’s share of servers worldwide, with most estimates pegging its stake at 40-50% of all web-facing servers.

This longevity is due to Apache’s scalability and strong development history. Apache is open-source, secure, feature rich, and continues to improve with its latest stable release in July 2016.

Apache’s age also means that there are a bevy of tips and tricks that can significantly increase your Apache install’s performance. Here are some essential tweaks that you can implement in less than an hour to significantly boost your server’s performance.

Optimize those modules!

Apache uses modules to extend its features far beyond the core httpd package. The downside is that modules tie up resources, and there’s a fair chance that an unoptimized Apache configuration is running at least a couple that aren’t needed.

It only takes a few minutes to check for and disable any modules that you may not be using. Check to see which modules are active:

apachectl -M

For Debian/Ubuntu installations, use these commands to easily enable/disable modules:

Enable: a2enmod module_name
Disable: a2dismod module_name

For RPM-based distributions like CentOS, it’s worth knowing that modules are loaded directly from the httpd.conf file. Start by creating a backup of httpd.conf, then open the file in an editor and simply comment out (#) any modules that aren’t needed.

To create a backup:

cp -p /etc/httpd/conf/httpd.conf /etc/httpd/conf/httpd.conf.YYYY-MM-DD.bak

Then make your edits:

vim /etc/httpd/conf/httpd.conf

The official Apache 2.4 docs list these modules as the bare minimum for operation:

mod_mime
mod_dir
mod_log_config

You can technically drop mod_log_config… but you won’t have any logs. This configuration also won’t run anything beyond the most basic static HTML site. Your module configuration is entirely dependent on what you need your server to be able to do.

A minimal Apache module setup for a WordPress site might look something like this:

mod_alias
mod_authz_host
mod_autoindex
mod_deflate
mod_dir
mod_expires
mod_headers
mod_log_config
mod_mime
mod_negotiation
mod_rewrite
mod_setenvif

That’s several additions to the original three, and your WordPress setup may actually require more depending on your configuration. For instance, if you have an SSL on your site, you’ll also need mod_ssl.

If you’re not familiar with the individual modules (or don’t want to look them up to see what they may be doing), you can still experiment with your site’s configuration by disabling modules sequentially and then testing your site to determine what works.

Know your MPM

Multi-Processing Modules (“MPM”) define the way that Apache handles requests. In order to get the most efficient and reliable experience out of your server, it’s important to use the configuration that best suits your setup. The three most common MPMs are Prefork, Worker, and the recently introduced Event.

List your current MPM:

Debian/Ubuntu –
apachectl -V | grep -i mpm

RPM –
httpd -V | grep -i mpm

To change your MPM, activate the proper module. For example, if you’re using Ubuntu and wish to switch from Prefork to Worker:
a2dismod mpm_prefork
a2enmod mpm_worker

And then verify that the change occurred:
apachectl -V | grep -i mpm

Prefork

Prefork (Pre-fork) is the oldest MPM, but it’s still a popular configuration. Prefork handles http jobs by creating child processes to serve those requests. Those processes then handle requests one at a time. As requests come in, Prefork attempts to create spare child processes that can wait for new requests. This system allows the server to remain free to handle additional requests by creating more child processes as needed.

Prefork works great until you encounter many concurrent connections, which even single users can generate very quickly due to the way that modern browsers operate. Generally speaking, the primary advantage of Prefork is that it’s compatible with most configurations and it’s very efficient, potentially even faster than threaded MPMs like Worker and Event, as long as you don’t need to serve a lot of concurrent requests.

Use Prefork if you need a lot of modules and don’t want to worry about compatibility (or thread-safe, i.e. when a code functions correctly during simultaneous execution by multiple threads). Many popular modules aren’t compatible with the threading used by Worker and Event MPMs, including mod_php, which is still commonly used despite the introduction of more efficient ways to serve PHP. You can check your modules for thread compatibility by using the Apache docs. You may also consider using Prefork if you need a site that runs very efficiently and you don’t expect large amounts of traffic.

Worker/Event

The Worker and Event MPMs uses multi-threading, which can handle significantly more concurrent requests by allowing child processes to spawn additional processes for requests. This differs significantly from Prefork, which only allows one request to be handled at a time by any given process. By using a threaded MPM, you can potentially boost your server’s performance by quite a bit, especially on high traffic sites. Lower traffic sites are less likely to see a change, as Prefork is less likely to hit max requests or be forced to use swap memory. Apache 2.4 saw the introduction of Event, which is similar to Worker except that it can use additional processes to handle portions of requests before closing a connection. According to the Apache docs, it is ok to use Event wherever Worker is also compatible. Event will simply fall back to processing requests identically to Worker if an incompatibility occurs.

Use the Worker or Event MPM if you know that your configuration is thread-safe. If you are currently using non thread-safe modules, you may want to consider checking for alternatives. For instance, in the case of the commonly used mod_php, FastCGI and PHP-FPM may be used instead. This change would not only give you the added benefit of using a threaded MPM, but also the benefit of a more efficient utility for delivering PHP.

In Conclusion

These are some small but nifty ways to speed up your Apache installation. Got any other tips? Feel free to add them to the comments below!