Introducing LAMP Tuning Techniques

I‘m getting to know far more about servers than I ever wanted to, afterhundreds of hours of Google research trying to squeeze/beat performance out ofApache. I do have 15 years programming experience in other areas, and I‘vereached the conclusion that the only experts in Apache/Linux are the programmerswho wrote (and poorly documented) all this stuff. So I‘ve gathered everything Icould learn after countless hours of frustration and I‘m writing this up inreturn for the immense amount of help I‘ve received from the documentation ofothers.
‘);//]]>
If you‘re reaching the limits of your Apache server because you‘re serving alot of dynamic content, you can either spend thousands on new equipment orreduce bloat to increase your server capacity from 2 to 10 times. This articleconcentrates on important and weakly documented ways of increasing capacitywithout the need for additional hardware.
Understanding Server Load Problems
There are a few common areas of server load problems, and a thousanduncommon. Let‘s focus on the top three I‘ve seen:
Drive Swapping , where too many processes (or runaway processes) use too much RAM.
CPU , from poorly optimized DB queries, poorly optimized code, and runaway processes.
Network , whether hardware limits or moron attacks.
Managing Apache‘s RAM Usage
Apache processes use a ton of RAM. This issue becomes major when you realizethat after each process has done its job, the bloated process sits andspoon-feeds data to the client, instead of moving on to bigger and betterthings. This problem is compounded by a bit of essential info that should reallybe more common knowledge:
If you serve 100% static files with Apache, each httpd processwill use around 2-3 megs of RAM.
If you serve 99% static files and 1% dynamic files with Apache, eachhttpd process will use from 3-20 megs of RAM (depending on yourMOST complex dynamic page).
Related Reading

Web Performance Tuning
Speeding up the Web
ByPatrick燢illelea
Table of Contents
Index
Sample Chapter
Read Online--Safari Search this book on Safari:  
Only This Book All of Safari
Code Fragments only
This occurs because a process grows to accommodate whatever it is serving,and NEVER decreases until that process dies. Unless you have very few dynamicpages and major traffic fluctuation, most of your httpd processes will soon takeup an amount of RAM equal to the largest dynamic script on your system. A verysmart web server would deal with this automatically. As it is, you have a fewoptions to manually improve RAM usage.
Reduce Wasted Processes by Tweaking KeepAlive
This is a tradeoff. The KeepAliveTimeout configuration settingadjusts the amount of time a process sits around doing nothing but taking upspace. Those seconds add up in a huge way. Using KeepAlive canincrease speed for both you and the client — disable it and the serving ofstatic files such as images may be a lot slower. I think it‘s best to haveKeepAlive on, and KeepAliveTimeout very low, perhapsone or two seconds.
Limit Total Processes with MaxClients
If you use Apache to serve dynamic content, your simultaneous connections areseverely limited. Exceed a certain number, and your system begins cannibalisticswapping, getting slower and slower until it dies. Personally, I think thesystem and/or web server should automatically take steps to prevent this, but bydefault, they tend to allow the server to consume itself. Use trial and error tofigure out how many Apache processes your server can handle, and set this valuein MaxClients.
Note: the Apache docs on this are misleading — if this limit is reached,clients are not "locked out," they are simply queued, and their access slows.Based on the value of MaxClients, you can estimate the values youneed for StartServers, MinSpareServers, andMaxSpareServers.
Force Processes to Reset with MaxRequestsPerChild
Forcing your processes to die after awhile makes them start over with lowerRAM usage. This can reduce total memory usage in many situations. The lessdynamic content you have, the more useful this will be. This is a game ofcatch-up, with your dynamic files constantly increasing total RAM usage, andrestarting processes constantly reducing it. Experiment withMaxRequestsPerChild (even values as low as 20 may work well), butdon‘t set it too low, because creating new processes does have overhead.
You can figure out the best settings under-load by examining ps axu--sort:rss. A word of warning: the results can be impressive, but are NOTconsistent. If the only way you can keep your server running is by tweakingthis, you will eventually run into trouble. That being said, by tweakingMaxRequestsPerChild, you may be able to increaseMaxClients as much as 50%.
Finally, think outside the box: replace or supplement Apache.
Use a Second Server
You can use a tiny, lightning fast server to handle static documents andimages, and pass more complicated requests on to Apache on the same machine.This way Apache won‘t tie up multi-megabyte processes serving simple streams ofbytes. You can bring Apache into play, for example, only to execute PHP scripts.Good options for this include:
TUX / "Red Hat Content Accelerator"
kHTTPd
thttpd
Try lingerd
Lingerd takesover the job of feeding bytes to the client after Apache has fetched thedocument, but requires kernel modification. It sounds pretty good, but I haven‘ttried it.
Use a Proxy Cache
A proxy cache can keep a duplicate copy of everything it gets from Apache,and serve the copy instead of bothering Apache with it. This has the benefit ofalso being able to cache dynamically generated pages, speeding up requests atthe expense of using more memory.
Recompile Apache
You could custom build Apache, with optimal settings for your situation,removing parts that you don‘t require. This is not for the faint of heart.
Replace Apache Completely
If you don‘t need all the features of Apache, replace it with something morescalable. Currently, the best options appear to be servers that use anonblocking I/O technology and connect to all clients with the same process. Thebest include:
thttpd
Caudium
Roxen
Zeus ($$)
Apache Tuning References
Apache docs on the above directives
Apache Performance Notes
Tuning Apache and PHP for Speed on Unix
Managing PHP‘s CPU and RAM Usage
Use an Accelerator
Compiling PHP scripts is usually more expensive than running them. Why notuse a simple tool that keeps them precompiled? Options include Turck MMCache(fast and free but buggy), PHP Accelerator, APC, and Zend Accelerator. You willlikely see a speed increase of 2 to 10 times and a PHP RAM reduction of 50%-85%.
SeeOptimizingPHP for more ideas.
Managing MySQL‘s CPU and RAM Usage
Optimize your Queries
This is covered in detail everywhere, so just keep in mind a few importantpoints. One bad query statement running often can bring your site to its knees.Two or three bad query statements don‘t perform much differently than one. Inother words, if you optimize one query you may not see any server-wide speedimprovement. If you find and optimize ALL your bad queries you may suddenly seea fivefold server-speed improvement. The log-slow-queries featureof MySQL can be very helpful.
Put your Volatile Data Somewhere Else
If you don‘t need all the extra features of a relational database, storingdata with your own method can be many times faster than MySQL. For temporarydata, store it in each user session, or globally with a shared memory library(like the one included with Turck MMCache). More important data can be stored infiles, or in your own flat-file database system. A combination of both could bevery powerful — your own flat-file database with a copy cached in memory, goingto disk only on write.
MySQL Tuning References
Getting maximum performance from MySQL
Tuning Server Parameters
Other Solutions
Here are a few other things you may find useful.
Use top and ps axu to check for processes that areusing too much CPU or RAM. But beware, these programs will actually lie to you.The total RAM used doesn‘t always match up — an application‘s threads share thesame memory pages, though it may not look that way.
Use netstat -anp | sort -u to check for network problems.
Use ApacheBench ab to benchmark your results — but keep in mindthis tool doesn‘t accurately simulate actual usage, most notably the effect ofmany dialup users, who keep connections open longer than you‘d like.
References
System Tuning Info for Linux Servers
mod_perl Performance Tuning (applies outside Perl)
Conclusion
If it makes you ill to think about a 20-meg process spending 15 secondswaiting on a KeepAlive after serving a 2k JPEG file, you‘re notalone! I come from the days of 1 MHz machines running multi-line BBSs. The ideathat gigahertz machines with gigabytes of RAM are being limited to 200simultaneous connections suggests that we‘re far more influenced by a certainmega-corporate mindset than we‘d like to believe. With some basic knowledge ofthe software and a few of the tips here, you can decrease the bloat and get yourserver running at least within a reasonable range of how it should, withoutinvesting in more hardware.