Re: Re: Linux and mm session handler -- does it really handle high load?

Hello Yasuo, Here's what I get when trying to compile the latest snapshot of PHP with your patch (on FreeBSD 4.2 -- I will try on Slackware 8 next): OD_SSL=208104 -DEAPI -DUSE_EXPAT -I/usr/home/rick/snaps.php/php4-20020206180 0/TSRM -g -O2 -prefer-pic -c session.c session.c: In function `php_session_start': session.c:850: `php_session_none' undeclared (first use in this function) session.c:850: (Each undeclared identifier is reported only once session.c:850: for each function it appears in.) session.c:940: `var' undeclared (first use in this function) session.c: In function `zif_session_set_save_handler': session.c:1133: `php_session_none' undeclared (first use in this function) session.c: In function `zif_session_unset': session.c:1421: `php_session_none' undeclared (first use in this function) *** Error code 1 Stop in /usr/home/rick/snaps.php/php4-200202061800/ext/session. *** Error code 1 Stop in /usr/home/rick/snaps.php/php4-200202061800/ext/session. *** Error code 1 Stop in /usr/home/rick/snaps.php/php4-200202061800/ext. *** Error code 1 Stop in /usr/home/rick/snaps.php/php4-200202061800. When I patched the source tree with your diff, here is the output: ----------- bash-2.04$ patch -p0 < session.diff Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |? ext/session/tmp.diff |? ext/session/bak |Index: ext/session//mod_files.c |=================================================================== |RCS file: /repository/php4/ext/session/mod_files.c,v |retrieving revision 1.67 |diff -u -r1.67 mod_files.c |--- ext/session//mod_files.c 3 Feb 2002 05:40:19 -0000 1.67 |+++ ext/session//mod_files.c 5 Feb 2002 03:24:15 -0000 -------------------------- Patching file ext/session//mod_files.c using Plan A... Hunk #1 succeeded at 16. Hunk #2 succeeded at 123. Hunk #3 failed at 138. Hunk #4 failed at 153. Hunk #5 succeeded at 257 with fuzz 1. Hunk #6 succeeded at 288. 2 out of 6 hunks failed--saving rejects to ext/session//mod_files.c.rej Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: ext/session//mod_mm.c |=================================================================== |RCS file: /repository/php4/ext/session/mod_mm.c,v |retrieving revision 1.31 |diff -u -r1.31 mod_mm.c |--- ext/session//mod_mm.c 25 Jan 2002 20:59:24 -0000 1.31 |+++ ext/session//mod_mm.c 5 Feb 2002 03:24:15 -0000 -------------------------- Patching file ext/session//mod_mm.c using Plan A... Hunk #1 succeeded at 319 with fuzz 1. Hunk #2 failed at 328. 1 out of 2 hunks failed--saving rejects to ext/session//mod_mm.c.rej Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: ext/session//php_session.h |=================================================================== |RCS file: /repository/php4/ext/session/php_session.h,v |retrieving revision 1.68 |diff -u -r1.68 php_session.h |--- ext/session//php_session.h 5 Feb 2002 01:28:55 -0000 1.68 |+++ ext/session//php_session.h 5 Feb 2002 03:24:15 -0000 -------------------------- Patching file ext/session//php_session.h using Plan A... Hunk #1 succeeded at 61 with fuzz 2. Hunk #2 succeeded at 84. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: ext/session//session.c |=================================================================== |RCS file: /repository/php4/ext/session/session.c,v |retrieving revision 1.275 |diff -u -r1.275 session.c |--- ext/session//session.c 5 Feb 2002 01:30:22 -0000 1.275 |+++ ext/session//session.c 5 Feb 2002 03:24:16 -0000 -------------------------- Patching file ext/session//session.c using Plan A... Hunk #1 succeeded at 87. Hunk #2 failed at 128. Hunk #3 succeeded at 480. Hunk #4 succeeded at 557 with fuzz 2. Hunk #5 failed at 581. Hunk #6 failed at 601. Hunk #7 succeeded at 755. Hunk #8 failed at 846. Hunk #9 succeeded at 940. Hunk #10 succeeded at 968 with fuzz 2. Hunk #11 succeeded at 1008. Hunk #12 succeeded at 1026. Hunk #13 succeeded at 1064. Hunk #14 succeeded at 1094. Hunk #15 failed at 1133. Hunk #16 succeeded at 1168. Hunk #17 succeeded at 1197 with fuzz 1. Hunk #18 succeeded at 1228. Hunk #19 succeeded at 1306. Hunk #20 failed at 1330. Hunk #21 failed at 1356. Hunk #22 failed at 1438. Hunk #23 succeeded at 1459. Hunk #24 succeeded at 1469 with fuzz 1. Hunk #25 succeeded at 1490. Hunk #26 succeeded at 1501. Hunk #27 succeeded at 1515. Hunk #28 succeeded at 1535. 8 out of 28 hunks failed--saving rejects to ext/session//session.c.rej Hmm... Ignoring the trailing garbage. done ----------- I made sure I had all my libs in the right place, AFAIK. Am I doing something wrong? ----- Original Message ----- From: "Yasuo Ohgaki" <yasuo_ohgaki@yahoo.com> To: <php-install@lists.php.net>; "Rick Morris" <rick@brainscraps.com> Cc: "Yasuo Ohgaki" <yasuo_ohgaki@yahoo.com> Sent: Wednesday, February 06, 2002 1:24 AM Subject: [PHP-INST] Re: Linux and mm session handler -- does it really handle high load? > Found the problem. It's actually in output layer, not > the patch. > > Just make sure you don't output any before starting > session/sending headers. PHP fails to complain about it > under my system and it caused segfaults. > > Here is my simple performance test reuslt > > [root@dev root]# ab -c 500 -n 5000 > > http://tmp-dev.localnet/~yohgaki/test/sess_save_handler/mm-handler.php > This is ApacheBench, Version 1.3d <$Revision: 1.58 $> apache-1.3 > Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ > Copyright (c) 1998-2001 The Apache Group, > http://www.apache.org/ > > Benchmarking tmp-dev.localnet (be patient) > Completed 500 requests > Completed 1000 requests > Completed 1500 requests > Completed 2000 requests > Completed 2500 requests > Completed 3000 requests > Completed 3500 requests > Completed 4000 requests > Completed 4500 requests > Finished 5000 requests > Server Software: Apache/1.3.23 > Server Hostname: tmp-dev.localnet > Server Port: 80 > > Document Path: /~yohgaki/test/sess_save_handler/mm-handler.php > Document Length: 30 bytes > > Concurrency Level: 500 > Time taken for tests: 37.948 seconds > Complete requests: 5000 > Failed requests: 0 > Broken pipe errors: 0 > Total transferred: 1923375 bytes > HTML transferred: 153870 bytes > Requests per second: 131.76 [#/sec] (mean) > Time per request: 3794.80 [ms] (mean) > Time per request: 7.59 [ms] (mean, across all concurrent requests) > Transfer rate: 50.68 [Kbytes/sec] received > > Connnection Times (ms) > min mean[+/-sd] median max > Connect: 3 539 656.8 432 9593 > Processing: 496 1612 2533.7 1323 33401 > Waiting: 411 1611 2533.7 1323 33402 > Total: 496 2150 2886.2 1872 37037 > > Percentage of the requests served within a certain time (ms) > 50% 1872 > 66% 1961 > 75% 2043 > 80% 2072 > 90% 2290 > 95% 2413 > 98% 5657 > 99% 11294 > 100% 37037 (last request) > [root@dev root]# > > > BTW, this Linux is running with 433Mhz Celeron PC. > > If you find problems, let me know. I might be able to fix > it before commit. > > -- > Yasuo Ohgaki > > Yasuo Ohgaki wrote: > > Looks like I've done something wrong. Older patch performs well but > > not this one. Don't even try the patch. > > > > -- > > Yasuo Ohgaki > > > > > > Rick Morris wrote: > > > >> I have tried mm as a session handler three times, on three different > >> Linux > >> boxes. Each one was a server under heavy load, running many concurrent > >> sessions, so I was hoping mm would solve some performance issues, but > >> have > >> been disappointed each time. > > > -- > PHP Install Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php >