Custom Query (310 matches)
Results (46 - 48 of 310)
Degraded performance when using Zend Guard encoded files with XCache 1.2.2 and Zend Optimizer 3.3.0
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.
Dmitri in touch
anonymous [email enclosed]
Hi Guys, it's Dmitri, author of DBG php debugger,
any chance to contact you by email?
Mine is ddmitrie[_at_]nusphere.com
Just want to help you fix one problem in xcache :)
Do not require a config.php for xcache-admin
Some variables like $enable_eval are accessed even though they are only defined in config.php.example.
Adding a isset() check before accessing such variables would make the config file optional and wont rise any PHP warnings.
This would make it a little easier to directly use the xcache admin distributed with the package.
for help on using queries.