Opened 6 years ago

Closed 2 years ago

#186 closed defect (fixed)

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
Priority: major Milestone: 1.3.0
Component: cacher Version: 1.2.2
Keywords: zend optimizer ioncube loader xcache slow Cc:
Application: PHP Version: 5.2.11
Other Exts: Zend Optimizer 3.3.0, ionCube Loader 1.3.24 SAPI: apache1
Probability: Always Blocked By:
Blocking:

Description

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

Test case:
Intel QuadCore? 2.4GHz
8GB ram
Debian w/ 2.4.36
Apache 1.3.31
PHP 5.2.6
PHP 4.4.7
Zend Optimizer v3.3.0
ionCube Loader 1.3.24
eAccelerator v0.9.5.3
XCache v1.2.2
APC v3.0.19



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


ionCube encoded

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


Notes:

  1. When using PHP5 Suhosin patch the time increases with 0.004-0.008 seconds
  2. The difference between PHP4 & PHP5 time was about 0.01 seconds more for PHP4 (yeah, obviously PHP4 is slower)
  3. The APC tests did not complete. The child process Sigfaulted all the time.
  4. Tests 3.1 and 3.2 used the original source code of the project.
  5. 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 :)


Regards,
Mihail Stoyanov

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:1 Changed 6 years ago by moo

  • Status changed from new to assigned

thanks, i'll see if i can steal some time this weekend for this ticket

comment:2 Changed 5 years ago by hoball

  • PHP Version changed from 5.2.6 to 5.2.11
  • SAPI changed from apache1 to FastCGI

Hello,

Are there any updates on this issue? I am having the same problem as well. Thank you.

Regards,
Hoball

comment:3 follow-up: Changed 5 years ago by hoball

  • SAPI changed from FastCGI to apache1

comment:4 in reply to: ↑ 3 Changed 5 years ago by hoball

Replying to hoball:
Sorry for the change of properties. I am using Lighttpd + FastCGI + ZendOptimizer?.

comment:5 Changed 2 years ago by moo

  • Milestone set to 1.3.0
  • Resolution set to fixed
  • Status changed from assigned to closed

this should have been fixed because XCache skip encoded file pretty well

Note: See TracTickets for help on using tickets.