Recently we did some work for a customer who has been struggling with keeping load under control. The servers run a few websites, and most of the web traffic is for a handful of sites that process lots of short web transactions in PHP against a MySQL backend database. Since each transaction is mostly unique, caching wouldn’t help.

We have heard some mixed reviews of Lighttpd and decided to test it out, since it was built mainly for speed and performance. With only about an hour’s work of building, configuring, and testing, we had a fully functional Lighttpd web server running with PHP running in FastCGI mode. FastCGI offers a way to keep PHP running in memory, independently of each web server process.

In most LAMP environments, PHP is running in Apache via an Apache module, mod_php. In this case, mod_php is loaded by each Apache child process. With all of the libraries and files required, this is not very effecient. FastCGI keeps php processes running on their own, and then php scripts are passed off to it by the web server processes when needed.

We were impressed by the results.

This first graph shows the load averages on one server over the course of several days. The green dot indicates the point when we switched one of the main websites on this server over to Lighttpd.

We just did another switch to Lighttpd on a similar type of server, where most traffic consists of short high-volume transactions. Both servers are running Apache and Lighttpd side by side, with some websites still running on Apache and the high traffic ones running on Lighttpd.

The PHP scripting language is very flexible and gives a lot of bang for the buck. However, it is often criticized by supporters of J2EE and other web development platforms for not scaling well. Nevertheless, we see plenty of large sites running on PHP as well as popular applications like Vbulletin.

Whenever a PHP script is run, mod_php or a php binary in CGI mode parses the script and spits the output to the web server to send along to the web browser. Basically, the php code is “compiled” on the fly. This works great until we start getting traffic to our site and have to compile the same code over, and over, and over again. Imagine having to compile an everyday program like Microsoft Office each time you load it - loading is already slow enough as it is! A PHP-driven site with lots of dynamic content will easy chew up the server’s CPU resources once the traffic hits hard enough.

Some advanced PHP applications use caching at the application level, such as Wordpress which now has some caching features. But what do you do when you have a large custom-written PHP content management system based on a sport that is now getting worldwide attention and traffic? That is the situation one of our customers was in recently. We implemented eAccelerator, an open-source project that implements caching in the PHP scripting engine. Their website explains that it “increases the performance of PHP scripts by caching them in their compiled state, so that the overhead of compiling is almost completely eliminated.”

Sure enough, eAccelerator worked as advertised. It cut the CPU usage on this particular server in half.