Drupalcon: Rasmus Lerdorf, PHP performance, and a Drupal performance correction
Today, on the first day of Drupalcon, Rasmus Lerdorf gave a fantastic presentation about PHP, performance, scalability and security. In this talk (the slides are available here), he discussed the writing of frameworks, and how they tend to trade off performance for what might be deemed as cleaner code. After walking through some very cool benchmarking methods (see slides 8, 14 and 16), he proceeded to benchmark some of the more popular PHP frameworks out there (slides 24 through 32). Unfortunately, when it came to Drupal, it was benchmarked without caching enabled. I have duplicated his Hello World module, and enabled it on a clean Drupal 6 install. While the absolute numbers are incomparible due to my local environment being different from his, I have run it without caching
Response time: 0.38 secs Transaction rate: 13.10 trans/sec
and then with aggressive caching enabled:
Response time: 0.04 secs Transaction rate: 119.42 trans/sec
The performance increases by roughly 9. By applying this ratio to his results for Drupal:
Response time: 0.10 secs Transaction rate: 51.37 trans/sec
the numbers would be something like:
Response time: 0.0105 secs Transaction rate: 468.5 trans/sec
With the pure html page coming in at about 610 transactions per second, Drupal 6.4 with aggressive caching enabled (as well as css and javascript optimization enabled) is much closer to that than any of the other applications/frameworks tested for the presentation. Of course, not having the exact same environment as Rasmus, I'm not sure if these results scale linearly, so this is mostly speculative. Even so, it takes Drupal a lot closer to that goal of not killing kittens, and a greener computing world.
Edit:
The above numbers were without APC enabled. With APC, the ratio is more like 5-6, so in that case, Rasmus' numbers would look like this:
Response time: 0.017 secs Transaction rate: 256.85 trans/sec
While not as good as those above, still these numbers come in very close to the best of the applications benchmarked by Rasmus.
Comments
Authenticated Users
Caching, like what you describe, only works for anonymous users. This really highlights the performance difference for authenticated and anonymous users.
thanks for links and research
Thanks for the links to the presentation and for your research into the performance numbers. I wonder if Rasmus enabled caching for any of the other frameworks.
It's quite interesting to me that adding APC slowed down the performance. APC has been confirmed in many examples to speed up PHPPHP (PHP: Hypertext Preprocessor) is a computer scripting language, originally designed for producing dynamic web pages. and Drupal, so I'm curious why your tests show this reverse situation.
APC
I don't think APC slowed down the performance in absolute numbers, just that ratio between cached & uncached decreased. That makes sense because APC reduces the cost of including more files.
iiiinteresting
I'd say that put a slightly different slant on things, but a lot of sites are not able to take advantage of aggressive caching, so there's still work to be done on that end.
registry patch
I thought it hilarious as he kept emphasizing Drupal's need to reduce the amount of code read-in customizing it to just what that particular user needed. I kept thinking, "registry patch, registry patch."
Post new comment