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.


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.


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 is installed via pecl, version 3.0.13, with default parameters.


eAccelerator is 0.9.5 installed from source using the following commands:

./configure   --enable-eaccelerator=shared
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/ 


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%
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%


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.


Another 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)

I'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.

Sat, 2008/07/19 - 08:10


I have also installed the eA but I have getting error log like

signal bus error (11). Can any one getting like this error.

Sat, 2007/04/07 - 13:10

Most 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. ;-)

Sat, 2007/06/02 - 21:10

I attended a talk at php|tek in Chicago given by Brian Shire of Facebook:


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.

Fri, 2007/08/17 - 10:45

Thanks 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!


Is your Drupal or Backdrop CMS site slow?
Is it suffering from server resources shortages?
Is it experiencing outages?
Contact us for Drupal or Backdrop CMS Performance Optimization and Tuning Consulting