Degraded performance when using Zend Guard encoded files with XCache 1.2.2 and Zend Optimizer 3.3.0
|Reported by:||screamer@…||Owned by:||moo|
|Keywords:||zend optimizer ioncube loader xcache slow||Cc:|
|Other Exts:||Zend Optimizer 3.3.0, ionCube Loader 1.3.24||SAPI:||apache1|
We are developing a PHP system which is encoded with Zend Guard/ionCube Encoder and as you may guess the Zend Optimizer/ionCube Loader is a "must" for us.
I personally like to squeeze every little percent of performance and that's why i had to pick the best op-code cacher.
Please note the tests below are NOT synthethic benchmarking.
The source code includes both encoded (when encoded of course) and non-encoded files, loads of classes, template generating+caching and MySQL queries (the time spent in mysql queries is stripped)
Intel QuadCore? 2.4GHz
Debian w/ 2.4.36
Zend Optimizer v3.3.0
ionCube Loader 1.3.24
Zend Guard encoded:
Test 1.1: Zend Optimizer only (all other modules disabled)
Page load time 0.069 seconds
Test 1.2: Zend Optimizer + XCache
Page load time 0.094 seconds
Test 1.3: Zend Optimizer + eAccelerator
Page load time 0.063 seconds
Test 2.1: ionCube Loader only (all other modules disabled)
Page load time 0.062 seconds
Test 2.2: ionCube Loader + XCache
Page load time 0.075 seconds
Test 2.3: ionCube Loader + eAccelerator
Page load time 0.056 seconds
Pure PHP source
Test 3.1: XCache only
Page load time 0.021 seconds
Test 3.2: eAccelerator only
Page load time 0.023 seconds
- When using PHP5 Suhosin patch the time increases with 0.004-0.008 seconds
- The difference between PHP4 & PHP5 time was about 0.01 seconds more for PHP4 (yeah, obviously PHP4 is slower)
- The APC tests did not complete. The child process Sigfaulted all the time.
- Tests 3.1 and 3.2 used the original source code of the project.
- For all ionCube Loader tests (2.x) we used PHP4
Now the big questions is - why XCache is slower when working with Zend Guard/ionCube encoded files?
As you may note it's far better if you don't use XCache at all if you have encoded files, or as in our case - use eAccelerator.
The tests with other op-code cachers are just to show that there is a way of speeding the things up.
Don't get me wrong - eAccelerator needs a lot of work to catch up with XCache. That's not the point of this ticket though.
The point is to show that there is a huge flaw in XCache when used with encoded files and 40-50% more time to generate a page for a production server is too much (imagine milion hits per day).
As we are big fans of Moo (and especially lighttpd project) we strongly believe you can fix it :)
P.S. If you need any beta testing, debugging or anything that i could be helpful - feel free to contact me at anytime.
Change History (5)
comment:2 Changed 4 years ago by hoball
- PHP Version changed from 5.2.6 to 5.2.11
- SAPI changed from apache1 to FastCGI