The bug was first planted in my ear when speaking with someone at Zend. Their claim was with the Zend Platform PHP scripts would execute 1 to 10 times faster. Plus the Zend Platform would compress data sent to the browser, monitor MySQL, and mange downloads.
At first the two things that appealed to me the most was the MySQL monitoring and the compressing of data being sent to the browser. For less money we ended up getting a license from MySQL that also provides support which is simply worth every penny. Doing a little research on the web took me to a great paper on , optimizing page load times.
What I learned from die.net was that I didn’t need any fancy software to do what Apache already had built in. There were some pretty common sense things to do, like having browsers cache images and javascript, compressing data sent to the browser, keepalives, etc.
After implementing many of these suggestions there was a noticeable improvement in performance. At least that was the perception when surfing lemonfree.com from my sister in-law’s dial-up connection in rural Saskatchewan. I was so happy with the results, that were evident from observation, that I hadn’t thought about caching PHP opcode or running benchmarks for a very long time.
One thing that really stuck with me from my research was that IBM recommended running eAccelerator in one of their papers about optimizing Apache and PHP. I figured that it was worth looking at if IBM recommended it. On top of that, techs at our hosting company had on occasion recommended using eAccelertor or the Alternative PHP Cache (APC).
I had installed APC on one server and eAccelertor on another server and really couldn’t tell if there was any benefit. I recall saying to a co-worker that lemonfree may or may not be any faster. I didn’t think it was slower. Since it was not obvious I decided to measure actual load times. Die.net came to the rescue here with a peice of Java code that measures the actual load times your users experience and records it in your apache logs. The code is as follows:
<head>
<title>...</title>
<script type="text/javascript">
<!--
var began_loading = (new Date()).getTime();
function done_loading() {
(new Image()).src = '/timer.gif?u=' + self.location + '&t=' +
(((new Date()).getTime() - began_loading) / 1000);
}
// -->
</script>
<!--
Reference any external javascript or stylesheets after the above block.
// -->
</head>
<body onload="done_loading()">
<!--
Put your normal page content here.
// -->
</body>
</html>
Now that I had a way to measure load times I ran three tests on a partner site, classifieds.carforums.net. I picked the partner site as there isn’t a large amount of Java Script or images to be displayed when compared to lemonfree.com. I figured that it should be easy to see the benefits on a simpler site.
The three tests were without caching, using eAccelortor, and finally using APC. I ran the tests for about a day each, the results are in the table below.
| Caching | Average | Median | Stdev | Max | Min | n | Start | End |
| No Cache | 2.5 | 1.25 | 5.2 | 161 | 0.12 | 9116 | 14/Jul:17:10 | 15/Jul:17:03 |
| PECL APC | 2.6 | 1.18 | 6.95 | 397 | 0.14 | 9488 | 16/Jul:10:41 | 17/Jul:10:40 |
| eAccelerator | 2.7 | 1.25 | 12.4 | 854 | 0.14 | 5902 | 15/Jul:17:04 | 16/Jul:10:41 |
Caching really had no impact on our partner site. What I liked about APC is that it gives you pretty graphs and tells you things like you’re hitting cached code 99.9% of the time but when you look at the actual page load times there really isn’t a benefit to caching PHP opcode with respect to page load times. Maybe on a less powerful server it would make a difference but on our partner site the bottle neck is certainly not the overhead from compiling PHP script.
I’ll be running a more in depth test on Lemonfree.com. We’re including page load times into our company targets and any change we make will also have the page load times factored in. I plan on running the tests for at least a week at a time on lemonfree.com and I’ll now in a month if caching is worth it on Lemonfree.
Demetri
