Update: We later conducted tests that include XCache and published them in our article on benchmarking Drupal with PHP op-code caches: APC, eAccelerator and XCache compared.
In an earlier article on PHP op-code caches and accelerators, we stated that empirical observations show that APC feels faster compared to eAccelerator.
We decided to run some benchmarks to validate this observation, and come out with some hard conclusions.
Drupal
So, we used Drupal 5.1, using a checkout of the repository as of March 5, 2007, as well as a HEAD checkout, which includes some menu system improvements by Karoly Negyesi (still work in progress).
All the core modules were enabled, but otherwise, it was a default install.
Hardware
The test was done on an AMD 64 3000+ test server with 1GB of RAM, 7200 RPM SATA disk.
System Software
We used Ubuntu Edgy 6.10, Apache 2.0.55, MySQL 5.0.24, and PHP 5.1.6.
APC
APC is installed via pecl, version 3.0.13, with default parameters.
eAccelerator
eAccelerator is 0.9.5 installed from source using the following commands:
phpize ./configure --enable-eaccelerator=shared make make install
The configuration parameters are as follows:
zend_extension = "/usr/lib/php5/20051025/eaccelerator.so" eaccelerator.shm_size = 0 eaccelerator.cache_dir = "/var/cache/eaccelerator" eaccelerator.enable = 1 eaccelerator.optimizer = 1 eaccelerator.check_mtime = 1 eaccelerator.shm_max = 0 eaccelerator.shm_ttl = 0 eaccelerator.shm_prune_period = 0 eaccelerator.shm_only = 0 eaccelerator.compress = 1 eaccelerator.compress_level = 7
Tests performed
The test was an ab2 run with 1000 requests for each configuration, using this command:
ab2 -n1000 http://head.example.com/
ab2 -n1000 http://5.example.com/
Results
The results are summarized in this table. Attached to this article you can find a spreadsheet (ODS format) with the raw data and calculations.
PHP | with APC | % over PHP | with eAccelerator | % over PHP | eA vs. APC | |
Drupal 5 | ||||||
Total seconds | 183.49 | 37.16 | 493.85% | 32.64 | 562.16% | 113.83% |
Requests/second | 4.45 | 26.91 | 604.72% | 30.64 | 688.54% | 113.86% |
millisecs per request | 183.49 | 37.16 | 493.86% | 32.64 | 562.15% | 113.83% |
HEAD | ||||||
Total seconds | 175.62 | 33.21 | 528.83% | 29.18 | 601.85% | 113.81% |
Requests/second | 5.69 | 30.11 | 529.17% | 34.26 | 602.11% | 113.78% |
millisecs per request | 175.62 | 33.21 | 528.83% | 29.19 | 601.71% | 113.78% |
Conclusion
On the test setup, both APC and eAccelerator show marked improvement over plain PHP. eAccelerator consistently faster by 13% over APC.
Other tests, not included in this benchmark, show that eAccelerator saves about 5MB per Apache process over APC, so there are other benefits. See the results for memory here.
Future tasks
We would like to benchmark Xcache against the above tests to see how it compares.
Comments
Visitor (not verified)
Another nice thing about eAccelerator...
Tue, 2007/03/06 - 02:02Another nice thing about eAccelerator is that it is compatible with the Zend Optimizer, whereas APC is not. This may not matter to a lot of people, but to anyone who needs to run Zend Optimizer it's really nice to know that an op-code cache is still available. (the Zend Optimizer for anyone who doesn't know already, is not much of an 'optimizer' at all in terms of speed)
Khalid
And xdebug too
Sat, 2007/06/02 - 21:20I also have it running alongside xdebug with no issues at all.
--
2bits -- Drupal and Backdrop CMS consulting
Visitor (not verified)
How do you get eaccelerator and xdebug working together?
Mon, 2007/08/06 - 13:29I'm able to get eaccelerator 0.9.5 and xdebug 2.0.0 installed at the same time, and I'm able to start a debug session with eaccelerator.enabled=0, but I'm not able to start a debug session while eaccelerator.enabled=1. Have you been able to get debugging working with eaccelerator enabled? If so, can you please post your php.ini file? Thanks.
Visitor (not verified)
It works fine with APC
Wed, 2007/11/14 - 04:49I know that Xdebug and APC work fine together... i don't see why not with eAccelerator.
Visitor (not verified)
eA
Sat, 2008/07/19 - 08:10Hi,
I have also installed the eA but I have getting error log like
signal bus error (11). Can any one getting like this error.
Visitor (not verified)
eA vs APC
Sat, 2007/04/07 - 13:10Most interesting. I used to be a big eAccelerator fan, but my faith has waned a bit, mostly since I started using Debian Etch servers with PHP V5.20 on high-traffic production sites. With eAccelerator in place, there are random apache child thread crashes, or the load average shoots to 150 with no clear explanation in the logs.
APC however, has been perfect. I do miss opcode optimization, but in this situation, stability is key. We're about to convert a very large site to drupal. ;-)
Khalid
eAccelerator stable on Ubuntu Feisty
Sat, 2007/06/02 - 21:19I upgraded from Ubuntu Edgy to Feisty, and with that came PHP 5.2.1. I compiled eAccelerator 0.9.5.1 with it and it is very stable.
I don't recall any segmentation faults since upgrading, but they were infrequent on Edgy too.
--
2bits -- Drupal and Backdrop CMS consulting
Visitor (not verified)
APC Locking strategy
Sat, 2007/06/02 - 21:10I attended a talk at php|tek in Chicago given by Brian Shire of Facebook:
http://www.scribd.com/doc/88689/apcfacebook
They use different locking mechanism than the standard File locking and get extra performance out of APC this way. I think with some tweaking APC can be as fast as Eaccelerator. It si also worth noting that Facebook has activelt contributed back code to APC, and they intend to keep improving it. They do a lot of data caching in APC though, which Drupal currently cannot.
Visitor (not verified)
Thanks for sharing that
Fri, 2007/08/17 - 10:45Thanks for sharing that presentation, I have been trying to find some better explanations of the locking mechanisms available for APC for a few months now. The Facebook team doesn't go into too much detail about each, but its at least enough for me to use as a reference.
Thanks again!
Visitor (not verified)
Thanks
Thu, 2007/09/06 - 23:44The facebook talk was actually very informative... thanks for the link!
-Alan
Pages