itst-Elfitst.net — 100 % β

[Update] PHP on Fire: Five Opcode Caches compared.

Out of curiosity I decided to invest a few hours and tested three PHP products that offer Bytecode (Opcode) Caching. There are five products available, of which I tested three:

Since I am a lazy turd, I used my development box for the benchmark, which runs WinXP Pro (SP2), Apache 2.0.59 and PHP 5.1.2. Installing and setting up either APC and XCache was easy enough. The Zend Platform gave me some headaches. It would not finish its installer, saying “Registering Node with the Zend Central”. After some trial and error (playing with the web server address - localhost, 192.168.1.10, 127.0.0.1), 127.0.0.1 and using “Express Installation” did the trick. Well, sort of. The weird message still doesn’t want to go away, but apparently everything works just fine. And very fine, how you will see soon.

But let me introduce the scripts used in the benchmark. First, a simple “Hello World!” script. Then the “Main”-tab of phpMyAdmin 2.8.2.4 and last but not least the homepage of a freshly installed MediaWiki 1.7.1. Since the latter two require a database, and thus a database server, here is what I currently use: MySQL 4.1.13, more or less out of the box. So nothing fancy here. PHP itself is equipped with two extensions, mbstring and mysqli. On top of that either APC, XCache, eAccelerator or ionCube. For the Zend Platform, the delivered Apache 2.0.50 and PHP 5.0.5 were used.

Each configuration was softly hammered with five tasks via ab:

  1. Execute helloworld.php 1000 times
  2. Execute phpMyAdmin/main.php 100 times
  3. Execute phpMyAdmin/main.php 1000 times
  4. Execute mediawiki-1.7.1/index.php/Main_Page 100 times
  5. Execute mediawiki-1.7.1/index.php/Main_Page 1000 times

The guys over at iPerSec did a similar benchmark. They added a timestamp change for the requested files to see how the cachers cope with that. Personally I believe that in a production environment such changes do not happen that often, so I skipped this suggestion.

OK, here the executive summary:

For all number-addicts, here’s the full chart (and a PDF if it, too).

26 comments

  1. Stefan says:

    Any special reason you chose to not include IonCube?

  2. Sascha says:

    Yeah. Simply skipped that the Encoder actually does bytecode caching. I will update this entry as soon as I get to it, possibly tomorrow evening. Thanks for the hint ;)

  3. […] PHP on Fire: Three Opcode Caches compared. at WWWorker - Sascha A. Carlin Out of curiosity I decided to invest a few hours and tested three PHP products that offer Bytecode (Opcode) Caching. There are five products available, of which I tested three: * Zend Platform * APC (APC GUI) * XCache * eAccelerator (tags: php tools performance tuning cache bytecode opcode comparision zend apc xcache) […]

  4. D Webber says:

    By the way, eAccelerator 0.9.5 is now out of beta (released Oct 11 2006) and seems to work okay with PHP 5.1 and 5.2. You might want to add it to your benchmarks too.

  5. Sascha says:

    Thanks for the info D. Looks like it will be a fun weekend ;)

    BTW, I did some first tests with IonCube. It looks promising so far.

  6. Sascha says:

    Just before the weekend ends ;)

    BTW, the +2000% for Zend Platform resulted from my messing up with copy&paste, sorry ;(

  7. […] Since my last benchmark was done on Windows XP, I will update it over the next days to include benchmarks run on Linux. Of course Linux would be more likely to power production environments, so it is only appropriate to test the opcode caches on Linux. […]

  8. Sencer says:

    You might want to add how you called ab (or ab2?) from the command-line and the output from ab (failed requests, statistical outliers pulling down the average etc.), and try out other values for concurrency as well. From my experience with greater concurrency (up to a point) the difference between opcode cache and plain old php becomes greater. Though granted - this may not be all that relevant for comparing between the different caches.

  9. Sascha says:

    Thank you for your suggestions, Sencer. This is the first time I publish such a benchmark and surely I can improve its worth by adding more data to it.

    For the record: I run ab with ab -n [100|1000] -c 10 {URL}. I chose a concurrency of ten because I wanted to primarily test the caches and not Apache HTTPD but add a bit of realism to the tests anyway. I will experiment with different settings. I see, this is going to take slightly longer than anticipated ;)

  10. Grigori says:

    PHP 5.2 with eAccelerator 0.9.5 starts to issue errors that it can’t access the protected fields (from within the object itself), and without debug it jsut segfaults.

    Also, I think it is not correct to test in windows and made my own benchmarks. XCache shows to be the same as APC, maybe insignificcantly faster on a single-CPU server. Though, XCache is reported to give bigger advantage in SMP.

  11. Heute möchte ich euch 2 Blogs von sehr engagierten Bloggern vorstellen. Als erstes haben wir hier Sascha, der in seinem heutigen Beitrag sehr sauer ist. Er hat im Oktober einen, wie ich finde sehr lesenswerten und äußerst informativen…

  12. jva says:

    Would you mind to check/compare the five with PhpExpress by NuSphere? http://www.nusphere.com/products/phpexpress.htm To me it appears that PhpExpress is pretty stable and brings no problems with existing scripts over APC and eAcceleartor that were crashing my site time after time when I tried them. Also, I’d mention that APC suffers from problems with include()/require(). I don’t want to rewrite my scripts and have absolute paths everywhere. Otherwise APC seems does not work. At least what works fine without APC does not work with it. EAccelearator was fast but it appeared that it does not lock shared memory and it’s what brought the performance. It turs out that in many cases it crashes as soon as your site gets any significant load with 100-500 scripts in use. Also, it is not compatible with debugger I use. Same goes for xcache which is nothing more but yet another derivation work of turk mmcache. So I still use PhpExpress and have no problems :)

  13. _ck_ says:

    Your chart says that eAccelerator has no “gui” but it does actually have a web management interface (just not installed/activated by default) - google the “eAccelerator control panel”

  14. […] What I needed to do was supercharge php and the easiest way to do that is by caching. Thanks to this interesting article on php caching by itst.net I chose APC (Alternative PHP Cache) which is supported by the php […]

  15. Sascha says:

    Thank you for your suggestions, Sencer. This is the first time I publish such a benchmark and surely I can improve its worth by adding more data to it.


    For the record: I run ab with ab -n [100|1000] -c 10 {URL}. I chose a concurrency of ten because I wanted to primarily test the caches and not Apache HTTPD but add a bit of realism to the tests anyway. I will experiment with different settings. I see, this is going to take slightly longer than anticipated ;)

  16. […] you’re interested in some benchmarks of XCache, eAccelerator, APC, etc. then checkout the Five Opcode Cache Comparison on PHP on […]

  17. mjglopez says:

    I'm still new to this op-code thingy. Quick question, do these accelerators have their own op-code format or do they all follow the Zend way of doing it? Would it be possible to dump APC opcode and have Zend run it? (It may sound stupid, so sorry in advance)

    Second question, is it possible to dump Zend op-code and run it straight thereby skipping the lexing, parsing, and compiling stage? If so, how is Zend op-code saved from memory to file and how is it executed?

    Thanks!

  18. 1: Actually, I'd rather say - without having tried it - that you might fall into some incampatability traps here.

    #2: To obtain the performace increases, Zend (and all OpCode caches) use filestamps to assess whether to compile anew or to run the existing opcode. How to dump Zend's OpCode from memory - I have no clue ;) You might get an answer at the Zend Developer Zone at http://devzone.zend.com/public/view

  19. mjglopez says:

    Thanks Sascha. I'll take a look at the link you gave.

  20. […] a partire dalla versione 2.8 come:Wordpress is a Memory Hog,How to cut down wordpress memory usage,PHP on Fire: Five Opcode Caches compared,Wordpress and Server RAM: Your (many) Plugin Uses (much) MemoryBehold WordPress, Destroyer of CPUs […]

  21. […] The most popular are Xcache, eAccelerator etc. See link for more info here. […]

  22. McFly says:

    Thanks! I will try APC and eAccelerator.

  23. kiev says:

    Im using eAccelerator and glad with a result. My full set of optimization consist of nginx(front end)+apache+eaccelerate+memcached. Try out.

  24. […] Five of them (APC, Zend Optimizer, XCache, ionCude Encoder and eAccelerator) are compared here http://itst.net/654-php-on-fire-three-opcode-caches-compared .  I am going to review APC and its impact on performance of a Magento […]

  25. […] the compiled bytecode of php scripts. You can see a benchmark here (albeit an older article): http://itst.net/654-php-on-fire-three-opcode-caches-compared Note: I strongly recommend using opcode […]

Your take?