Benchmarking APC vs. eAccelerator using Drupal

Published Tue, 2007/03/06 - 00:05, Updated Sat, 2008/09/20 - 11:18

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.

If you disable compression

If you disable compression for eAccelerator, you will get even better results. There is no need for compression these days: memory and disks are cheap. Just give 128M to eAccelerator in SHM, that's it.

comparison between eAccelerator and apc

Very interesting post.
I tried eAccelerator (I followed these instructions: http://www.valent-blog.eu/en/2009/02/18/eaccelerator/) and apc. eAccelerator is the fastest opcache but I need to compile it and this is a security problem (I have Debian Etch before and now I am testing Lenny), so we must install complilation softwares and then remove them.
Apc is a little slower then eAccelerator but no build tools are required.
I did not try Xcache, maybe in future.
Compliments, I bookmark your post.

Another comparison

Here is another comparison that compares all of the three free ones.

benchmarking Drupal with PHP op-code caches: APC eAccelerator and XCache compared.

I still use, and recommend, APC because it is the most stable and stays up to date with PHP releases.

Concurrency

I see the benchmark only uses 1000 requests and not providing multiple concurrency levels, which is a more typical usage. I would test with "-c" from 5 to 20.

Thank you very much for such an interesting article

Thank you very much for such an interesting article

Thank you! I went with

Thank you! I went with eAccelerator - it's easier to install than APC. This just confirms my choice. There are just too many PHP thingamajigs - it's hard for a novice like me to know which one to pick.

Drupal is complex system

Drupal is complex system with many scripts includes. Try to set PHP variables:
realpath_cache_size = 256K
realpath_cache_ttl = 180

and you can get performance boost by 10%-50%.

Serious awesome tip

wonderfull...
just folow your post.
simple tip with awesome output.

Thanks alot
You are my Hero.

Thanks

Thanks for the tip.

Did you check to see if this has an effect when the server has an op-code cache (e.g. APC), vs. without an op-code cache?

If you are using an op-code cache, I would think that these parameters do not matter at all, and would have no effect.

On the other hand, on shared hosts where you don't have an op-code cache, these may provide some help.
--
2bits -- Drupal consulting

thanks!

Thanks for the hard work on this study. I have wondered how effective eAccelerator really is for dymanic sites like Drupal. After reviewing the study, I have compiled it and installed it on my test server.

APC Locking strategy

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

Thanks

The facebook talk was actually very informative... thanks for the link!

-Alan

Thanks for sharing that

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!

eA vs APC

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

eAccelerator stable on Ubuntu Feisty

I 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 consulting

Another nice thing about eAccelerator...

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)

eA

Hi,

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

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

And xdebug too

I also have it running alongside xdebug with no issues at all.

-- 2bits -- Drupal consulting

How do you get eaccelerator and xdebug working together?

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.

It works fine with APC

I know that Xdebug and APC work fine together... i don't see why not with eAccelerator.

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