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

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

moo (8 matches)

Ticket Summary Component Milestone Type Created
Description
#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.3 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) ...

#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.

#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 对。

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

#241 Compiled Code For eval() cacher 1.3.3 enhancement 04/26/2010

The biggest performance issue we see these days is there is no good way to eval compiled code.

It would be *really* nice if XCache could intercept eval() calls, generate a md5 hash based on the code to be run, compile that code with the md5 as the internal key if the key isn't already compiled/stored in memory. Then execute the compiled version of the code.

#253 reduce the number of fstat call to help server on SAN and network file servers cacher 1.3.3 enhancement 10/19/2010

Adding a parameter to indicate a modification time check delay for php opcode cache can help reduce the load for php server with root directory on a SAN or any network file system. The fstat cost with such setup is much higher than on local filesystem.

This can be implemented this way:

Adding a struct member with the last m_time check in the cache entry. Check this entry and compare it with the request time, if the last check is within the specified delay (10 seconds for example), use the cache entry as is. If the last check time is older, read the m_time, update the last check time and do the timestamp compare as now.

#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

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