APC vs Zend vs MMCache vs Ioncube
The other day I was analysing a bunch of different encoder/optimizers for PHP to determine what the best solution would be for a specific project. What they needed was the ability to encode our php scripts as well as cache/optimize our server to increase our site speed. They were currently using mmcache as our encoder/optimizer, however due it the lack of support and several bugs (especially for high trafficed sites) they needed to move to a different solution. I eveluated APC , Zend Platform w/ the Zend Encoder, Ioncube w/ php accelerator and MMCache. I used apache flood to do all of my tests. A few things to note. Zend was run with encoded files using the zend encoder. Ioncube/php accelerated used ioncube encoded files. MMCache was tested with mmcache encoded files. APC was tested with no encoded files as APC has no encoder. However I did test APC with Source Guardian and found after some preliminary test that they worked alright together. Also all encoders were setup using Apache 1.3.33 and PHP 4.4.0 except for mmcache which used Apache 1.3.33 and PHP 4.3.9. The reason for using the lower version of PHP for mmcache was because of the foreach bug with it and any later version of PHP.
I did 4 different tests ranging from 500 requests to 10,000 requests on over 20 different php scripts that all did different types of things (database access, filesystem access, straight output etc). Here are my results calculated in number of requests per second.
510 Requests
APC: 19.17
mmcache: 16.11
Zend: 19.47
Ioncube: 10.7
3000 Requests
APC: 19.63
mmcache: 19.69
Zend: 18.72
Ioncube: 10.82
5,000 Requests
APC: 19.6
mmcache: 19.51
Zend: 20.37
Ioncube: 11.06
None: 7.39
10,000 Requests
APC: 19.09
mmcache: 19.19
Zend: 18.93
Ioncube: 10.74
None: 7.14
So from these results you can see that APC and Zend show very similar results, yet cannot surpass the speed of mmcache. It must be a testiment to MMCache in that it hasn’t seen any new development since 2003 yet still is top of the field (shame about the bugs however). Lastly I was pretty disapointed with the results of Ioncube, only being able to produce about half the number of requests per second as Zend and APC.
As for which product they will choose I am unsure as of now. APC has the strong benefit of being free, however not having an encoder may make them lean in the direction of Zend.
Lastly to note the reason I never included eaccelerator in these tests is because it contains many of the same bugs that MMCache has regarding high load situations, mainly apache deadlocks. It is sad really because the people who need a good encoder/optimizer are those who are under high load situations. Anyway it doesn’t look like the eaccelerator crew really has it’s stuff together either way with a pretty inactive development team.
So take what you want from these test results, they are by no means is it the last word, but simply my findings after a few days of testing.
4 comments
hello. great information.
one more question about
protecting source-code:
IONcube claims that their propietary technology is likely unbreakable and better than the others.
is this right ?
i couldnt find what what weaknesses of
the competitors…
may be you know what
they are pointing to.
we have two different
king of web-applications:
- those ones that requires security instead of speed
- and those ones that
required acceleration
dispate of sacrificing some security.
thanks in advance
and very usefull information,
jesus
I think the reason Ioncube claims to be better is that some of these encoders such as mmcache/eaccelerator and source guardian just encode to a form of bytecode, such it can be translated back to PHP code. The Zend encoder however I think is pretty strong as well. You are right though, there are two questions at play here, how much you value the security of your scripts, and how much you the value the speed at which they run. Personally I would love to see an encoder for APC, that would ideal.
Can you elaborate a little on eAccelerator? I’ve been running eAccelerator in production for several months, and with production I mean that those are websites that handle 200+ GB of web traffic monthly. I did not encounter any Apache deadlocks.
Till do you have any of your php files encoded? I think it is caused by the encoded processes. Basically what happens is you will start to see a lot of segfaults going through your logs on a random script, then eventually apache stops responding. There is a bug report about it that has never been solved. Have talked to all the people with the same issues and they told me they had the same problems, nothing changed… Here is the link to the bug:
http://sourceforge.net/tracker/index.php?func=detail&aid=1091402&group_id=122249&atid=692864
It has been open since 2004 still no fix. Also you will probably find a bunch of segfault bugs in there as well… You are pretty lucky not to have this problem. We face having to restart our webservers weekly/bi-weekly depending on when apache locks up.
If you don’t need encoding ability I would highly suggest that you use APC instead, it is pretty stable with a really good development team (hey when you have Rasmus Lerdorf as one of the developers you know you are in good hands). Anyway those are just my 2 cents. If eaccellerator is working error free for you, then you have nothing to worry about, why change something that is working well.