Turck MMCache for PHP

I have heard quite a lot of good reports on how Turck MMCache for PHP can improve performance. Performance does not just matter the high traffic sites, but with sites hosted on over-saturated shared hosting, or on a wimpy box like mine, it is still a good thing to have PHP performing well, especially considering how many inefficiently programmed PHP scripts are out there.

So, what is Turck MMCache then? From its website:

Turck MMCache is a free open source PHP accelerator, optimizer, encoder and dynamic content cache for PHP. It increases performance of PHP scripts by caching them in compiled state, so that the overhead of compiling is almost completely eliminated. Also it uses some optimizations to speed up execution of PHP scripts. Turck MMCache typically reduces server load and increases the speed of your PHP code by 1-10 times.

The emphasis is mine, but that is exactly what attracted me to it. Who else is not tempted by the idea of “reaping without sowing“?

So I downloaded the latest stable release from SourceForge (Release 2.4.6), followed the instruction to build it as a PHP extension, installed it and restarted Apache. Initial impression – well, it seems to be faster, but it is definitely no where near 10 times the speed. I then proceeded with some benchmarking.

Here’s the spec of my wimpy server:

Server: Dual Celeron 400Mhz, 384Mb RAM, 60Gb 7200RPM HDD. BogoMIPS 800
OS: Linux yang.id.au 2.4.19-16mdksmp
Apache: Apache-AdvancedExtranetServer 1.3.26
PHP: Mod_PHP 4.2.3
MySQL: MySQL 3.23.56

And some benchmark result. These are done using Apache benchmark application making 100 requests from the web server with no concurrency.

Page Size [bytes] Req per Second [#/sec] Time Per Req [ms] Speed Up [%]
NC MM NC MM NC MM
FOCUS Forum 10,175 0.69 0.71 1,440.27 1,416.11 100 102
Playground Index Page 21,723 0.61 0.75 1,652.69 1,331.03 100 124
Playground Individual Page 24,053 0.90 1.22 1109.50 820.92 100 136
FOCUSer.net Index Page 12,139 10.82 37.92 92.44 26.37 100 350

NC=No Cache. MM=Turck MMCache.

As my not-so-scientific benchmark has shown, there is some speed up, ranging from “pathetic” to “oh, great!”. The already fast pages now load even faster, but the slower pages of mine only get tiny bits of boost.

FOCUS Forum index page is derived from an ancient copy of Phorum, and it is heavily MySQL driven. I would imaging that most of the time it is waiting for complicated queries to return. MySQL 3.23 is not very good at dealing with complicated joins. Instead of relying on a PHP cache/accelerator to increase the performance, I should have either optimised the queries or updated to the latest MySQL 4 server.

Playground is WordPress powered, and I found “the loop” that loads the blog entries from database can sometimes generate queries that put MySQL 3.23.x into disadvantage. At the same time, I am using 3 content filters with WordPress, including Matt’s Texturize, my Scripturizer and Syntax Hilighter. Regular expression is heavily used in these content filters. Since regular expression in PHP is implemented in C, Turck MMCache can really do nothing to help it…

However, Movable Type generated static pages from FOCUSer.net have much noticable performance boost from MMCache. Each request invokes only 2 simple SQL queries, and most logics are done in plain PHP. However, it is already quite fast, making it even faster does really little to the load of the whole box.

Conclusion

What is the verdict? Turch MMCache is great – it increases the performance of your PHP scripts without any code re-writes. The cost is minimal – just install it, set up a cache directory, restart Apache, and hopefully everything should feel faster.

However, it does not address many performance issues inside the programming logic. It provides a faster VM, but it does not make someone a better programmer. To truly tune a system for maximum performance, one still needs to write efficient algorithms, code optimised database queries, utilise static cache or even re-code the bottleneck with a compiled-to-machine-code language.

Or just buy a bigger box :)

Category: Uncategorized | Tue, 22 June 2004 12:50 pm
Tags:

Comments

1.
Avatar for Tom
Posted by Tom on Tue, 22 June 2004 1:00 pm

However, it does not address many performance issues inside the programming logic. It provides a faster VM, but it does not make someone a better programmer. To truly tune a system for maximum performance, one still needs to write efficient algorithms, code optimised database queries, utilise static cache or even re-code the bottleneck with a compiled-to-machine-code language.

Or just buy a bigger box :)

Most of the time, the second option is always cheaper.


2.
Avatar for scotty
Posted by scotty on Wed, 23 June 2004 9:56 am

Cheaper – for one solution maybe.

Not if your solution is deployed over thousands of sites. Hardware upgrade on that would be quite costly. And there are some instances where you just cannot scale up.


Add a comment

Gravatar is used. Email address is required but will not be displayed. Please keep your comment on topic. No spamming and/or bad language. First time poster will be moderated. Scott reserves the right to delete/edit your comments.