{ "href": "/post/2008/09/04/rasmus-lerdorfs-laconica-performance/", "relId": "2008/09/04/rasmus-lerdorfs-laconica-performance", "title": "Rasmus Lerdorf's Laconic(a) Performance", "author": "pmjones", "markup": "html", "tags": [ { "href": "/tag/benchmarks/", "relId": "benchmarks", "title": "Benchmarks", "author": null, "created": null, "updated": [], "markup": "markdown" }, { "href": "/tag/php/", "relId": "php", "title": "PHP", "author": null, "created": null, "updated": [], "markup": "markdown" } ], "created": "2008-09-04 16:44:38 UTC", "updated": [ "2008-09-04 16:44:38 UTC" ], "html": "

As many of you know, I maintain a series of web framework benchmarks. The project codebase is here and the most recent report is here.

\n

It was with some interest, then, that I viewed Rasmus Lerdorf's slides on the subject of performance benchmarking. I'm beginning to think there's something unexpected or unexamined in his testing methodology.

\n

\n

Note: see the update at the end of this entry.

\n

On this slide, Rasmus notes the following:

\n\n

This would seem to indicate that the mere invocation of PHP, on Rasmus' setup, reduces Apache's performance from serving static pages by less than 1%.

\n

In my testing on Amazon EC2 small instances, I note somewhat different results:

\n\n

The net reduction there is about 43%. Yes, this is with opcode caching turned on.

\n

I then became really curious as to how Rasmus might have his system set up, to see only a 1% bit of \"added overhead\" from PHP being invoked. It would be nice if I could set up my own systems the same way.

\n

When I asked about that at work, my colleague Elizabeth Smith opined that maybe Rasmus' web server is running all requests through the PHP interpreter, not just PHP files. That sounded like a good intuition to me, so I set up an EC2 instance to try it out.

\n

Per the setup instructions on this page I built an EC2 server the same as I've done for my own benchmarking reports. I didn't check out the whole project, though; this time we just need the \"bench\", \"baseline-html\", and \"baseline-php\" directories.

\n

As a reminder, the baseline index.html page is just the following plain text ...

\n
Hello World!\n
\n

... and the baseline index.php page is the following single line of PHP code:

\n
<?php echo 'Hello World!'; ?>\n
\n

The php5.conf file for Apache looks like this by default ...

\n
<IfModule mod_php5.c>\n  AddType application/x-httpd-php .php .phtml .php3\n  AddType application/x-httpd-php-source .phps\n</IfModule>\n
\n

... and we're going to leave it alone for a bit.

\n

Using ab -c 10 -t 60 to benchmark baseline-html and baseline-php with the default php5.conf gives us these results (an average over 5 runs each):

\n
               |      avg\n-------------- | --------\nbaseline-html  |  2367.02\nbaseline-php   |  1270.15\n
\n

That's a 47% drop for invoking PHP. (That is itself 4 points different than the numbers I show above, so it appears there are some variables I have not controlled for, or maybe I just need to let this run longer than 5 minutes to smooth out the deviations.)

\n

To test our hypothesis, we modify the php5.conf file to add .html to the list of files that get passed through PHP ...

\n
<IfModule mod_php5.c>\n  AddType application/x-httpd-php .html .php .phtml .php3\n  AddType application/x-httpd-php-source .phps\n</IfModule>\n
\n

... restart Apache, and run the same ab tests again:

\n
framework      |      avg\n-------------- | --------\nbaseline-html  |  1348.80\nbaseline-php   |  1341.31\n
\n

That's less than a 1% drop -- close enough to make make me think that Rasmus might be pushing everything through the PHP interpreter, regardless of whether or not it's a PHP file.

\n

If that is true (and it's a big \"if\"), then merely invoking PHP does appear to cause about a 45% drop (give or take) in Apache's responsiveness, which is contrary to the point Rasmus makes on this slide about PHP \"rarely\" being a bottleneck -- and I say that as someone who works with PHP almost exclusively. In fairness, I am depending only on the text of his slides here, so he may have said something to that effect in the presentation itself.

\n

Failure modes on this analysis:

\n\n

I can't imagine those three differences would lead to the kind of disparity in performance that I'm seeing, but it's possible.

\n

Has anyone else tried doing this?

\n

Rasmus, if you have the time and inclination, would you care to shed some light on these prognostications?

\n

Update: Is It EC2?

\n

Rasmus replies below that he did not, in fact, have PHP running for all .html files.

\n

For me, the next question was to see what the real difference on EC2 is between no cache, XCache, and APC.

\n

No cache:

\n
\n               |      avg\n-------------- | --------\nbaseline-html  |  2339.25\nbaseline-php   |  1197.28\n
\n

XCache (copied from above)

\n
\n               |      avg\n-------------- | --------\nbaseline-html  |  2367.02\nbaseline-php   |  1270.15\n
\n

APC:

\n
\n               |      avg\n-------------- | --------\nbaseline-html  |  2315.83\nbaseline-php   |  1433.91\n
\n

So on EC2, you get about 1200 req/sec without caching, about 1300 req/sec with XCache, and about 1400 req/sec with APC, in the \"hello world\" baseline scenarios.

\n

Maybe this is all an artifact of how EC2 works, then? I have no idea. Next step is to test on non EC2 systems, if I can find one that others can reasonably build on themselves (since one of the goals here is for others to be able to duplicate the results).

\n" }