Re: [VOTE] RFC: Introduce session_start() options - read_only, unsafe_lock, lazy_write and lazy_destroy
Hi all,
On Mon, Jan 26, 2015 at 6:42 AM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
> On Thu, Jan 22, 2015 at 2:05 PM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
>
>> I've made patch for master since PHP 5.6 is released already.
>>
>> https://wiki.php.net/rfc/session-lock-ini
>> https://github.com/php/php-src/pull/1016
>>
>> Except comments, changes are almost minimal, but includes a few bug fixes
>> that tests equality of PS(session_status) against "php_session_none". The
>> comparison must be "PS(session_status) != php_session_active" as it has
>> php_session_disabled. I also removed 2 needless session globals.
>>
>> Comments are appreciated.
>> This patch boosts PHP application performance a lot when session data
>> have not changed. It's faster than benchmark in the wiki because hashing
>> has removed.
>>
>> If I don't have any comment in a few days, I'll merge it to master.
>>
>
> I've updated UPGRADING and UPGRADING.INTERNALS and ready to merge.
> I'll wait a day more. Please comment on github if you have.
>
I've tried to get some benchmarks. It seems current system is too fast to
get obvious performance difference.
Test command: ab -c 7 -n 500000 http://localhost:8888/session.php
Test script:
<?php
ini_set('session.save_path', '/home/tmp');
ini_set('session.lazy_write', 1); // Change mode here
ini_set('session.use_strict_mode', 0);
session_id('testid');
session_start(['read_and_close'=>0]); // Change mode here
//$_SESSION['test'] = ++$_SESSION['test'];
$_SESSION['a'] = str_repeat('a', 102400);
echo '<pre>';
var_dump(session_id(), $_SESSION['test']);
?>
Old behavior was around 15000 reqs/sec.
"read_and_close" improved it to about 20000 reqs/sec. i.e 33% faster.
"lazy_write" did not improve # of reqs, but per process httpd disk writes
was reduced from 100 MB/s to 5 MB/s. i.e. There were 12 httpd processes,
1200 MB/s writes was reduced to 60 MB/s writes. Note: Linux kernel(btrfs)
does not actually write data to disk when the data is the same.
I think this would be good enough benchmark for merging.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Thread (13 messages)