Custom Query (312 matches)


Show under each result:

Results (46 - 48 of 312)

Ticket Resolution Summary Owner Reporter
#361 invalid Couldn't making separate xcache variable cache for each php-fpm pool moo ntman

Couldn't making separate xcache variable cache for each php-fpm pool

This is very pitiful limitation. Because I can't divide variable cache by several users for shared hosting and etc.

Also expected that for each pool I can setup own xcache password.


# cat /etc/php-fpm.d/poligon.conf [poligon] listen.owner = nginx = nginx listen = /var/run/php-fpm/poligon.sock

user = poligon group = poligon pm = dynamic pm.max_children = 50 pm.start_servers = 5 pm.min_spare_servers = 5 pm.max_spare_servers = 35 ;slowlog = /var/www/mikhail/logs/php-fpm-slow.log ;php_admin_value[error_log] = /var/www/mikhail/logs/php-fpm-error.log php_admin_flag[log_errors] = on ; Set session path to a directory owned by process user php_value[session.save_handler] = files php_value[session.save_path] = /tmp php_value[soap.wsdl_cache_dir] = /tmp ; xCache administration php_value[xcache.admin.user] = "poligon" php_value[xcache.admin.pass] = "0c51a8dd180d8a3360c88de27057c587"

#138 fixed Crash with long xcache.mmap_path moo judas_iscariote

we have a crash with :

php -dxcache.mmap_path="/tmp/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" -r 'echo "foo";'

SEGV on 0x00002ac028a2c9d8 in zm_post_zend_deactivate_xcache ()

in anycase xcache.mmap_path should not be longer than MAXPATHLEN

#186 fixed Degraded performance when using Zend Guard encoded files with XCache 1.2.2 and Zend Optimizer 3.3.0 moo screamer@…

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


  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 :)

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.

Note: See TracQuery for help on using queries.