Unload/Remove Unneeded/Unused Modules : In Ubuntu and Debian based systems, you’ll see a folder called /etc/apache2/mods-enabled and a folder called /etc/apache2/mods-available/. The mods-available folder is a list of all the modules installed on a particular server and mods-enabled is the modules that are currently active.
Unfortunately, the modules you need may not be precisely clear because some are dependencies of others.
What I suggest doing is making a list of all the currently active modules and saving it for future reference in case you need to revert back. Then simply disable modules one-by-one and restart your Apache after each change to see if errors occur.
On Ubuntu and Debian, you disable a module with the command (using autoindex as an example):
sudo a2dismod autoindex
To enable it back
sudo a2enmod autoindex
Some modules that are particularly resource hungry that you should disable if you don’t need them are:
- Rack / Ruby / Passenger
Several of those modules are not enabled by default, so you may not have them enabled, and in some cases, they’re enabled because you actually need them.
A quick note about “rewrite”: Often this module is enabled when the “alias” module would actually work equally well. If you can get by with alias then disable rewrite. Rewrite is one of the more burdensome modules, but it also imbues Apache with some remarkable powers.
Limit the Number of Apache Processes and Children:
Most operating systems’ default Apache configurations are not well suited for smaller servers– 25 child processes or more is common. If each of your Apache child processes uses 120MB of RAM, then your VPS would need 3GB just for Apache.
One visitor’s web browser may request 4 items from the website at once, so with only 7 or 8 people trying to load a page at the same time your cloud server can become overloaded. This causes the web page to hang in a constantly loading state for what seems like an eternity.
It is often the case that the server will keep these dead Apache processes active, attempting to serve content long after the user gave up, which reduces the number of processes available to serve users and reduces the amount of system RAM available. This causes what is commonly known as a downward spiral that ends in a bad experience for both you and your site’s visitors.
What you should do is figure out how much RAM your application needs, and then figure out how much is left, and allocate most of that to Apache.
For example, if you have three php-fpm processes handling dynamic content, and each can use up to 70MB of RAM, and your MySQL server may use up to 120MB of RAM, that combines for a total of 330MB used by the application. This allows you to allocate about 150MB to Apache.
While Apache is running open the top command on the server. I’ll paste a little bit of what you’d see, trimming out most of the lines that aren’t pertinent:
top -bn 1
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
5111 www-data 20 0 232m 9644 1900 S 0.0 1.6 0:00.02 apache2
5112 www-data 20 0 232m 9644 1900 S 0.0 1.6 0:00.01 apache2
5113 www-data 20 0 232m 9644 1900 S 0.0 1.6 0:00.02 apache2
Notice the RES column for an Apache child process and make note of its RES value. For example, on my virtual server which has been well optimized, the value is 9,644, which means it’s using not quite 10MB of RAM. If I limit Apache to a maximum of 15 child processes, then it should max out at about 150MB of RAM.
Edit your cloud server’s apache config file, which on Ubuntu and Debian is /etc/apache2/apache2.confand locate the section for the mpmpreforkmodule configuration. Look for the MaxClients line and set it to 15, then save and restart Apache.
Here is an example of what you’ll look for in Ubuntu: More explanation given separately.
See the MaxClients line there? We need to change that value to a lower number.
If your VPS gets overloaded, and reaches the maximum number of clients it can serve at once, it will serve those and other users will simply get a quick failure. They can then reload the page and maybe have greater success on the second try.
This sounds bad, but believe me, it’s much better to have these connections close quickly but leave the server in a healthy state rather than hanging open for an eternity. Surprisingly you can get better performance from a server that has fewer child processes but responds faster than it is to have a server with more child processes that it is unable to handle.
Case in point, a WordPress site I manage is hosted on a 1GB droplet using 4 php-fpm processes and is able to serve over 950 simultaneous users at one time. This translates to a peak capacity of about 42 million page views per day, should this website ever become popular enough!