{5} Assigned, Active Tickets by Owner (Full Description) (11 matches)

List tickets assigned, group by ticket owner. This report demonstrates the use of full-row display.

moo (11 matches)

Ticket Summary Component Milestone Type Created
Description
#159 White pages after raising size to any greater than 0 cacher 1.3.0 defect 12/30/2007

Hi,

i'm fiddling around with xcache for some hours now but i can't get any more than white pages after raising size to any greater than 0 - googling around didn't help unfortunately :( any idea?

I'm running php 5.2.5 and apache.


#37 xcache_get SEGV using objects cacher 1.4.0 defect 09/24/2006

PHP 5.1.6 xcache_get SEGV with objects.

<?php
//php built in stdClass
xcache_set("foo" , new stdClass);
var_dump(xcache_get("foo"));

?>

well, I expect either and error if objects are not supported, or the actual stored object var_dump'ed but not a segv :)


#53 500 error with Wordpress coverager 1.3.0 defect 11/17/2006

Hi, I'm seeing a 500 error returned in Wordpress. It is fixed with either a restart of the php fastcgi processes, or clearing the xcache cache from the xcache admin page.

It is not with all Wordpress pages, so far I've seen it when posting a comment. Posting comments works fine for a few hours/days then consistently returns a 500 error.

This is with php5-cgi 5.1.2-1ubuntu3.4 package on Ubuntu Dapper running as a fastcgi process under lighttpd. It's with xcache 1.1.0 compiled from source (and observed from at least xcache trunk svn r262).

I get no error output from php (to the error_log or php stderr) when accessing the broken page (though I know php error logging to be working).

I think the php script causing the problem is wp-comments-post.php but I've got a couple of comment related plugins installed, such as Akismet and a threaded comments plugin.

I've got other Wordpress installations on the same box which *reportedly* had the same problem (but at different times), though I've not seen it myself.

I'm getting no coredump on the error.

root@mule:~# gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.0 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-java-awt=gtk-default
--enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre
--enable-mpfr --disable-werror --with-tune=pentium4
--enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.0.3 (Ubuntu 4.0.3-1ubuntu5)

root@mule:~# php-cgi -v
PHP 5.1.2 (cgi-fcgi) (built: Nov  2 2006 12:24:48)
Copyright (c) 1997-2006 The PHP Group
Zend Engine v2.1.0, Copyright (c) 1998-2006 Zend Technologies
    with XCache v1.1.0, Copyright (c) 2005-2006, by mOo

#95 Memory is not free()'d after xcache_get() data is unset cacher 1.4.0 defect 05/15/2007

I've tested EA vs XCache performance on cache reads and got the following problem:

Code:

<?php
    function ea_read ($max) # void
    {
        global $DATA;

        for($i = 0;$i<10;$i++)
        {
            $key[$i] = 'some_key_'.$i;
            eaccelerator_put($key[$i], $DATA);
        }

        for($i = 0;$i<$max;$i++)
            $val = eaccelerator_get($key[$i%10]);
    }

    function xcache_read ($max) # void
    {
        global $DATA;

        for($i = 0;$i<10;$i++)
        {
            $key[$i] = 'some_key_'.$i;
            xcache_set($key[$i], $DATA);
        }

        for($i = 0;$i<$max;$i++)
        {
            $val = xcache_get($key[$i%10]);
        }
    }

Result ($max = 10000):

<?php
    $DATA = str_repat('x',10000); 

Everything is ok.

<?php
    $DATA = array_map('uniqid', range(1,10));

Fatal error: Allowed memory size of 16777216 bytes exhausted (tried to allocate 15 bytes).

It seems that XCache somehow marks array items that they aren't released (may be it increases ref_count?). I tried to add "unset($val);" after "$val = xcache_get();" but it didn't help.

The only solution I've found is:

<?php
   xcache_set($key,serialize($data));
   $val = unserialize(xcache_get($key));

but it looks weird (and slows down xcache calls) ...


#161 xcache keeps on crashing, core attached cacher 1.3.0 defect 01/14/2008

Hello

xcache keeps on crashin. I have three core files saved with an identical backtrace:

Core was generated by `/usr/sbin/apache2 -k start'.
Program terminated with signal 11, Segmentation fault.

(gdb) bt
#0  0x00002b215f95f887 in xcache_fcall_end_handler () from /usr/lib/php5/20060613/xcache.so
#1  0x00002b215aef5db2 in get_zend_version () from /usr/lib/apache2/modules/libphp5.so
#2  0x00002b215af00cd5 in zend_hash_apply () from /usr/lib/apache2/modules/libphp5.so
#3  0x00002b215aef6247 in zend_post_deactivate_modules () from /usr/lib/apache2/modules/libphp5.so
#4  0x00002b215aeb473a in php_request_shutdown () from /usr/lib/apache2/modules/libphp5.so
#5  0x00002b215af75943 in php_ap2_register_hook () from /usr/lib/apache2/modules/libphp5.so
#6  0x0000000000432cf9 in ap_run_handler ()
#7  0x0000000000435e72 in ap_invoke_handler ()
#8  0x0000000000441fe8 in ap_process_request ()
#9  0x000000000043f4cc in ap_register_input_filter ()
#10 0x0000000000439851 in ap_run_process_connection ()
#11 0x0000000000445961 in ap_graceful_stop_signalled ()
#12 0x0000000000445bd4 in ap_graceful_stop_signalled ()
#13 0x0000000000445c76 in ap_graceful_stop_signalled ()
#14 0x00000000004468cd in ap_mpm_run ()
#15 0x0000000000420e70 in main ()

I'm running xcache-1.2.2 with apache 2.2.3-4+etch3 + php5-5.2.5 on a Debian 4.0 'etch' system with the following config:

web8:/var/cache/apache2# php -i|egrep '(jit|xcac)'

/etc/php5/cli/conf.d/xcache.ini,
auto_globals_jit => Off => Off
xcache.admin.enable_auth => On => On
xcache.cacher => On => On
xcache.coredump_directory => no value => no value
xcache.count => 8 => 8
xcache.coveragedump_directory => no value => no value
xcache.coverager => Off => Off
xcache.gc_interval => 0 => 0
xcache.mmap_path => /var/cache/apache2/php_xcache => /var/cache/apache2/php_xcache
xcache.optimizer => Off => Off
xcache.readonly_protection => 1 => 1
xcache.shm_scheme => mmap => mmap
xcache.size => 128M => 128M
xcache.slots => 16K => 16K
xcache.stat => On => On
xcache.test => no value => no value
xcache.ttl => 0 => 0
xcache.var_count => 2 => 2
xcache.var_gc_interval => 300 => 300
xcache.var_maxttl => 0 => 0
xcache.var_size => 32M => 32M
xcache.var_slots => 8K => 8K
xcache.var_ttl => 0 => 0

It's gone now and I saw a warning that I set xcache.mmap_path to a directory. Maybe that was the resason but still it definetly should not segfault!

As I had segfaults under Load for a couple of days now :(

bye,

-christian-


#186 Degraded performance when using Zend Guard encoded files with XCache 1.2.2 and Zend Optimizer 3.3.0 cacher defect 07/15/2008

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.


#142 support for php 5.3 cacher enhancement 10/30/2007
/home/builder/rpm/pld/BUILD/xcache-1.2.1/utils.c: In function `xc_redo_pass_two':
/home/builder/rpm/pld/BUILD/xcache-1.2.1/utils.c:183: error: structure has no member named `is_ref'
/home/builder/rpm/pld/BUILD/xcache-1.2.1/utils.c:184: error: structure has no member named `refcount'
/home/builder/rpm/pld/BUILD/xcache-1.2.1/utils.c:187: error: structure has no member named `is_ref'
/home/builder/rpm/pld/BUILD/xcache-1.2.1/utils.c:188: error: structure has no member named `refcount'
/home/builder/rpm/pld/BUILD/xcache-1.2.1/utils.c: In function `xc_do_early_binding':
/home/builder/rpm/pld/BUILD/xcache-1.2.1/utils.c:376: error: structure has no member named `is_ref'
/home/builder/rpm/pld/BUILD/xcache-1.2.1/utils.c:410: error: structure has no member named `is_ref'
/home/builder/rpm/pld/BUILD/xcache-1.2.1/utils.c:411: error: structure has no member named `is_ref'
make: *** [utils.lo] Error 1

#179 新 API 建议 cacher enhancement 05/31/2008

一般情况下,在执行的 PHP 脚本中,很少会只用一次两次的 var cache。

都会这么写: foreach ($data AS $key => $value) {

xcache_set($key, $value, $ttl);

}

xcache_get 也基本上差不多,尤其在把数据库的记录当作一个 key -> value 对存在的时候,往往做一个列表页的情况下,会进行很大批量的 get 和 set 操作。从性能开销的考虑来看,由 xcache 支持批量操作,速度会提升 5-10 倍。目前 APC 和 MEMCACHE 的 get 操作都支持批量 key 的存取。我想除了方便的角度,也有性能提升的考虑吧。

我设想增加 xcache_gets API,原型为:

array xcache_gets(array $keys, [array &$unget_keys])

变量 keys 为一批 key,变量 unget_keys 为在缓存中未获得到的 key 的数组。方便后期代码中进行数据的获取,而不需要再进行循环操作。

如果可以的话,也可以增加 xcache_sets 函数,原型为:

bool xcache_sets(array $data, $ttl)

变量 $data 为 key -> $value 对。

以上建议请希望开发者慎重考虑~


#79 coredump on oom cacher 2.0.0 defect 03/08/2007

xcache.size=1M, non debug build

analyze result: ce->parent need to be fixed, because parent class is copied into class_table and changes the pointer of parent class after sandbox_install. this is php4 only


#173 win php5.2 distribution - admin does not include header.tpl.php and footer.tpl.php cacher 1.3.0 defect 04/19/2008

Hi After following the installation steps, the admin directory does not contain the header and footer.tpl.php files. When calling the admin in the browser error messages regarding missing files are generated. Joel


#107 Add "per-second" stats to xcache admin admin 1.4.0 enhancement 06/27/2007

It would be useful in the admin pages to have the Hits, Misses, Clogs and OOMs shown both as totals like they are at the moment and additionally as per-second values. Also a column to show when each cache was last cleared would be nice.


Note: See TracReports for help on using and creating reports.