In this post, I’m going to cover the basics behind optimizing an Apache/LAMP web server. There are many many great resources out there for getting into the nitty gritty of each of these topics, and I will be posting more about some of them on this blog over time, but simply googling a topic should get you a wealth of information about them.
Possibly one of the best books I’ve found as a linux resource is Linux Server Hacks (Link) Which also now has a volume 2 (also found on amazon). This book is a great resource for any Linux admin or hobbyist, and includes quick how-to summaries for common problems. Overall, a great reference book for those times where you need to quickly get an answer on how to do something without reading into a ton of detail about it.
When Optimizing LAMP/Apache, there are five key pieces to look at: 1) Hardware, 2) Linux, 3) Apache, 4) MySQL, 5) PHP. I’m going to cover the basics of each one, one at a time.
1 – Optimizing your hardware for web serving.
One of the first places to start, is to make sure you’re running on good hardware. Special consideration should be paid to what web apps your running. If you’re serving static HTML and Images, you can get away with minimal hardware. As you move into more dynamic sites, with lots of PHP and Database access, you’re going to want to look at adding more RAM and faster Hard Drives. In a web server, especially with the performance level of modern CPU’s, there are three places you’re likely to run into bottlenecks. 1) Network Bandwidth. The only way to solve this is to ensure you’ve selected a good hosting partner, and that they have a robust, low latency network. 2) Disk I/O. This is far less of an issue on small sites, but as your site grows, at least some of your traffic is going to be spent pulling data from the hard drive. There are several options to mitigate this, the most common being to move to SSD Hard drives, or to use RAID arrays (I recommend RAID-1 mirrored pairs for read heavy servers and limited budgets, and RAID-5 arrays of at least 4 drives for anything else). 3) Memory. The more RAM you have in your server, the less often the system needs to flush data out of it and go back to the hard drives to get it again. More RAM is also helpful in preventing swapping when server access gets high. RAM is cheap these days, so load up as much as you can!
2 – Linux
Now that you have your hardware selected, lets move on to the OS. Any linux distribution is fine, and you’re best to pick the one you’re most comfortable with, as it will make your administration easier. I personally like to use RedHat based distributions (CentOS, Feodra, or RHEL) as that’s what I’m more familiar with. FreeBSD or OpenBSD also make excellent web servers, and allot of the tips in this article hold true there as well. The first thing to do on the OS side is to strip away and disable anything you don’t need for your server. This not only adds security risks, but also consumes memory that can be used for other tasks. Things like Samba, and CUPS should all be disabled, or simply never installed. Next, patch all the various packages on the system, to ensure you have the most up to date versions for security and performance. Once that’s done, you should ensure that you configure IPTables if the server is directly connected to the internet. If you’re behind a firewall, this isin’t as important, but you may still wish to look into it.
3 – Apache
Current versions of Apache have a huge number of features and configuration options, so you really need to be careful not to take any one internet “how to” too literally, as some of the directions in an article may cause issues with the site you’re deploying. You should first start by disabling unused modules in the Apache httpd.conf file (typically found in /etc/httpd/conf/httpd.conf). Each unused module you load takes up memory space that you can better use for other things. A second place to look, which is essential in preventing crashing due to memory use, is the “MaxRequestsPerChild” variable in the worker and prefork modules. This limits how many requests an apache process will serve before it shuts down and re-spawns. There’s a fine balance here, between keeping memory use low, and site performance high, and you’ll need to tune this specifically to your needs. The larger the files/scripts on your site are, the larger the memory allocation of each Apache process will get over time, as it caches these files. A few other places to look when tuning the server include: Trying to avoid multiple .htaccess files in a directory tree, as each one needs to be loaded and checked before any request is served. Disable hostname lookups in your Apache configuration, as this adds a performance hit to resolve host names, that you likely don’t care about. This information can always be parsed in batch later by something like webalizer. If you’re really going for speed, you can disable apache logging, this does make troubleshooting harder, but saves you the disk I/O of writing logs. Lastly, the server-status and server-info pages (enabled by flags of the same name in the apache conf file) add a very small performance hit and should be disabled unless they’re being used specifically (eg: for Munin monitoring).
4 – MySQL
Tuning MySQL is somewhat akin to voodoo. That said, the goal with MySQL performance is to use the MySQL cache’s as often as possible, and avoid reading from Disk if you can help it. One of the best tools for perfomance tuning MySQL is the MySQLtuner pearl script (which can be downloaded on your system by using wget or curl, from here: http://mysqltuner.pl/mysqltuner.pl ). This script will analyze your MySQL install and offer tuning suggestions. Weigh these suggestions against the amount of RAM in your system (you may need to limit some of the increases due to memory constraints) and make the changes where appropriate. Once you’ve made and implemented the changes, come back the next day, and check again, and again. MySQL Optimization will take several days, as you need server accesses to properly gauge where the load is going. Another great tool for this is Munin, as the graphs it generates for MySQL can provide valuable insight over the long term to see what is happening. These two tools combined should provide you with more than enough details to make your MySQL install substantially faster than the out of the box version your OS was setup with.
5 – PHP
PHP is an interesting beast. Every time a script is executed, it has to be compiled first, and then run via an Apache module to produce results that are sent to the client. The best place to optimize PHP is on the script level. If you have control over writing the PHP code, start combing through it to see if there are routines that can be optimized, or database calls that can be trimmed down, as this will make the biggest difference in PHP Performance. If you don’t have that option, then the next biggest performance gain you’ll get is from an opcode cache. What this does is cache the compiled PHP scripts so that they can be re-used, and skip the compilation step each time they’re requested. Two of the most popular opcode caches are APC and eAccelerator. Be careful to monitor the opcode cache to ensure it’s working properly, as they can cause issues if not properly configured. Lastly, check your php.ini file, and ensure you’re memory limits are set to reasonable numbers. You want to provide PHP with just enough memory to run the largest script you have, but not such a large amount that it’s a waste.
Hopefully this provides a basic starting point of where to look for optimizations on your web server. I will be posting more articles on specific items here in the coming months. Stay Tuned!
