Note: This is part 2 in a series on Apache in a LAMP environment. You can read part 1 here.

Now that we’ve covered the common directives, and how they relate to each other, let’s talk about some tweaks to make Apache hum in your environment. We will assume that you know where to find the referenced files.

What we’ll cover in this post is all contained here (a copy of my own VPS’s Apache directives).


KeepAlive On
MaxKeepAliveRequests 150
KeepAliveTimeout 5
<IfModule prefork.c>
StartServers 10
MinSpareServers 10
MaxSpareServers 20
MaxClients 150
MaxRequestsPerChild 500
</IfModule>
<IfModule worker.c>
ServerLimit 5
StartServers 2
MinSpareThreads 25
MaxSpareThreads 75
ThreadsPerChild 25
MaxClients 150
MaxRequestsPerChild 500


Timeout 300

Understanding the implications of any changes you make to your configuration is essential, but a lot of that knowledge will come with experience. Here is my take on three of the directives, and some of the things you can do with them.

1: MaxClients.

This directive defines how many simultaneous and independent requests will be served by Apache. There are two things to consider before you change this setting.

• What is the current setting?

By default Apache uses a setting of 150. This is a good starting point but it’s probably low for dedicated servers. Slowly ncrease it in increments of 25-50. If it’s already at 500 or 1000 then increasing it more may not be the right answer.

• How much memory/CPU does your site take per page load? How much memory/CPU do you have left?

You want to allow pages to be served. You don’t want to crash the server. If your site is normally memory or CPU intensive and you don’t have much to spare you will want to think carefully before increasing it.

If MaxClients is reached new requests are queued rather than being served immediately. This will appear to clients like a really long load time. Check your error log for this error:

[Sun Jun 06 18:00:15 2010] [error] server reached MaxClients setting, consider raising the MaxClients setting

There are a couple ways to handle this. The most obvious is increasing that number. You can also use a command like netstat to determine if there is a single IP address that has a lot of connections to port 80 on your server. My favorite piece of bash-fu:

netstat -tn 2>/dev/null | grep :80 | awk '{print $5}' | cut -f1 -d: | sort | uniq -c | sort -rn | head

That will collect a list of all of the open connections to port 80 and sorts the 5th field in that string. Depending on your system you might need to tweak the line to sort by the correct field. The ‘Foreign Address’ field is the one you want.

2. KeepAlive

KeepAlive is an on/off setting. It determines if a connection to the client will remain open after Apache serves its request. If your server is high traffic or is serving a lot of small and/or flat files then turning KeepAlive off can significantly reduce resource use by Apache.

Beware, though, that changing this directive is not as predictable as with the others. If you decide to change it on an a server that is experiencing problems at the time you should keep a close eye on your server’s load and your finger on the kill -9 trigger.

3: MaxRequestsPerChild

MaxRequestsPerChild defines how many requests a single Apache child would serve before it was killed and a new child spawned. In a shared environment this can be very helpful to negate the effects of memory leaks in the web server. By default this setting is 1000. A good value for this setting in a shared environment is 150% of your MaxClients directive.

If you are serving the same static, predictable content you can safely pump this directive up pretty high. This will decrease the amount of times that Apache has to kill and spawn new children. 10,000 is a good setting for higher traffic servers with stable/static content. If you like to live dangerously you can set it to ’0′ (unlimited). If you increase it beyond 150% you might consider writing a script that will monitor your server’s memory use and alert you if it gets too high.

---

Apache configurations are very subjective. Once you understand each directive you’ll find that you develop your own best practices. Since most configuration tweaks are born out of necessity you will probably find yourself making these changes under fire. Good luck. :)