Re: [PHP-DEV] Performance degradation part 2 the module version
On Mon, 24 Feb 2003, Rasmus Lerdorf wrote:
if (stream) {
if (self-is_pipe) {
stream-flags |= PHP_STREAM_FLAG_NO_SEEK;
} else {
stream-position = ftell(file);
}
}
We should be able to skip that ftell() call on a script or include file we
have just opened, right?
Yes; prior to my fixes this week, the ftell was sometimes important;
streams should be able manage just fine without it now.
_php_stream_open_wrapper_as_file() what are you trying to guard against
with that stream_cast call?
if (php_stream_cast(stream,
PHP_STREAM_AS_STDIO|PHP_STREAM_CAST_TRY_HARD|PHP_STREAM_CAST_RELEASE,
(void**)fp, REPORT_ERRORS) == FAILURE)
{
php_stream_close(stream);
if (opened_path *opened_path)
efree(*opened_path);
return NULL;
}
We have already stat()'ed the file to death. We know it is there, that we
are allowed to open it, etc. What could go wrong that the open call just
above it wouldn't have caught? Is it just a case of getting too general
and we need a special-case simpler function for the most common operation
of simply opening script files?
Yes and no. (we need this approach in order to be able to
include/require from any wrapper).
In php_stream_cast, we need to ensure that when we pass back the file
pointer, it is seeked to the correct offset (as we see it) in the file.
This is because the underlying FILE* has its own buffer, and its own
idea of the file position.
[Yes, using FILE*/stdio streams with buffers is causing headaches, which
is why I'm moving away from them in PHP 5].
Admittedly, when opening the file for the first time, we do not need to
seek - so we can avoid it by passing a flag (OR'd with the REPORT_ERRORS
flag).
I'm sure we can eliminate those seeks. Are there any other areas in the
streams code that you can see that could do with a syscall tune-up?
--Wez.
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Performance degradation part 2 the module version
Admittedly, when opening the file for the first time, we do not need to seek - so we can avoid it by passing a flag (OR'd with the REPORT_ERRORS flag). I'm sure we can eliminate those seeks. Are there any other areas in the streams code that you can see that could do with a syscall tune-up? Those are the only ones I have seen so far that stood out as being extraneous. I think we should do our best to add whatever shortcuts are necessary to ensure the most common execution path is as fast as we can possibly get it. If it takes getting a little ugly passing in flags, so be it. I'd like to get 4.3 up to the same level as 4.2. I still need to hack and slash away code for Yahoo! on top of that since syscall thrashing is our limiting factor at this point. There is other ugliness hiding in there. For example, include_once on a file that has already been included will still stat() (many times) and open() the file. Only later on does it go and check the included_list to see if it should actually have done that. Not quite on the primary execution path, but still. If you have a case where that scenario happens a lot, it is actually mesurably faster to do manual multiple include prevention with a PHP-level flag. The _once stuff was added distinctly to prevent that kind of ugly code, but we stuffed it up. -Rasmus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Performance degradation part 2 the module version
I'm sure we can eliminate those seeks. Are there any other areas in the
streams code that you can see that could do with a syscall tune-up?
Ok, found two more. In _php_stream_fopen() we fstat() the script to be
opened:
realpath = expand_filepath(filename, NULL TSRMLS_CC);
fp = fopen(realpath, mode);
if (fp) {
/* sanity checks for include/require */
if (options STREAM_OPEN_FOR_INCLUDE (fstat(fileno(fp), st) == -1 ||
!S_ISREG(st.st_mode))) {
#ifdef PHP_WIN32
/* skip the sanity check; fstat doesn't appear to work on
* UNC paths */
if (!IS_UNC_PATH(filename, strlen(filename)))
#endif
goto err;
}
ret = php_stream_fopen_from_file_rel(fp, mode);
That sequence of code is a trainwreck. The expand_filepath() ends up
doing an lstat() on every component of the path and then the file itself,
and then we fstat() the file. I can't afford the realpath() here, so I
turn it off in expand_filepath(), but I don't think the fstat() is needed
there.
Then right after that in _php_stream_fopen_from_file() we have:
#ifdef S_ISFIFO
/* detect if this is a pipe */
if (self-fd = 0) {
struct stat sb;
self-is_pipe = (fstat(self-fd, sb) == 0 S_ISFIFO(sb.st_mode)) ? 1 : 0;
}
#endif
which does yet another fstat() on the file. At the very least, this one
should use the result of the previous one. Basically if these checks are
still needed, we need a stat cache here.
There is a 3rd fstat() after that, but I can't really make any sense of
the backtrace to it:
#0 0x202d0c58 in fstat () from /usr/lib/libc.so.4
#1 0x202e42e6 in __swhatbuf () from /usr/lib/libc.so.4
#2 0x202e4236 in __smakebuf () from /usr/lib/libc.so.4
#3 0x202d454f in __srefill () from /usr/lib/libc.so.4
#4 0x202b3ea6 in fread () from /usr/lib/libc.so.4
#5 0x203f9bb4 in yy_get_next_buffer () at Zend/zend_language_scanner.c:5359
#6 0x203f98cd in lex_scan (zendlval=0x9fbfd770) at Zend/zend_language_scanner.c:5193
#7 0x20401814 in zendlex (zendlval=0x9fbfd76c) at
/homes/rasmus/php4/Zend/zend_compile.c:2459
#8 0x203f38e8 in zendparse () at /home/y/share/bison.simple:432
#9 0x203f6685 in compile_file (file_handle=0x9fbff758, type=2) at
/homes/rasmus/php4/Zend/zend_language_scanner.l:348
#10 0x2040b3a6 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at
/homes/rasmus/php4/Zend/zend.c:860
#11 0x203e41ce in php_execute_script (primary_file=0x9fbff758) at
/homes/rasmus/php4/main/main.c:1591
#12 0x204235d6 in apache_php_module_main (r=0xdc040, display_source_mode=0)
at /homes/rasmus/php4/sapi/apache/sapi_apache.c:55
#13 0x2042419e in send_php (r=0xdc040, display_source_mode=0, filename=0x0)
at /homes/rasmus/php4/sapi/apache/mod_php4.c:617
#14 0x204241fe in send_parsed_php (r=0xdc040) at
/homes/rasmus/php4/sapi/apache/mod_php4.c:632
#15 0x48e84 in ap_invoke_handler (r=0xdc040) at http_config.c:518
#16 0x59cec in process_request_internal (r=0xdc040) at http_request.c:1352
#17 0x59d47 in ap_process_request (r=0xdc040) at http_request.c:1368
#18 0x52977 in child_main (child_num_arg=0) at http_main.c:5229
#19 0x52b18 in make_child (s=0xa4930, slot=0, now=1046217441) at http_main.c:5400
#20 0x52c49 in startup_children (number_to_start=25) at http_main.c:5498
#21 0x53165 in standalone_main (argc=2, argv=0x9fbffa80) at http_main.c:5859
#22 0x538ec in main (argc=2, argv=0x9fbffa80) at http_main.c:6246
-Rasmus
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Performance degradation part 2 the module version
On Sun, 23 Feb 2003, Wez Furlong wrote:
This double seeking is most probably due to the fact that the stdio
layer does one set of seeking, whereas streams needs to do another.
This can be solved by moving away from using stdio for streams, and just
using the raw descriptors instead. (already made a start on this in
PHP 5).
I had a closer look at this. The seeks are not coming from the stdio
layer, they are coming directly from PHP. The first, SEEK_CUR +0 comes
from an ftell() call here in _php_stream_fopen_from_file():
if (stream) {
if (self-is_pipe) {
stream-flags |= PHP_STREAM_FLAG_NO_SEEK;
} else {
stream-position = ftell(file);
}
}
We should be able to skip that ftell() call on a script or include file we
have just opened, right?
And here is the backtrace for the second one:
#0 0x202e6c0f in lseek () from /usr/lib/libc.so.4
#1 0x203ef154 in php_stdiop_seek (stream=0xd640c, offset=0, whence=0,
newoffset=0x9fbfdcbc)
at /homes/rasmus/php4/main/streams.c:1493
#2 0x203ef868 in _php_stream_cast (stream=0xd640c, castas=-1073741824,
ret=0x9fbfdcf0, show_err=8)
at /homes/rasmus/php4/main/streams.c:1952
#3 0x203f04d6 in _php_stream_open_wrapper_as_file (path=0xddad8
/home/y/share/htdocs/test.php, mode=0x2043a223 rb,
options=141, opened_path=0x9fbff328) at /homes/rasmus/php4/main/streams.c:2506
#4 0x203e3b4e in php_fopen_wrapper_for_zend (filename=0xddad8
/home/y/share/htdocs/test.php, opened_path=0x9fbff328)
at /homes/rasmus/php4/main/main.c:727
The php_stdiop_seek() does a direct lseek() call. I don't really see why
this is needed either at this point. In
_php_stream_open_wrapper_as_file() what are you trying to guard against
with that stream_cast call?
if (php_stream_cast(stream,
PHP_STREAM_AS_STDIO|PHP_STREAM_CAST_TRY_HARD|PHP_STREAM_CAST_RELEASE,
(void**)fp, REPORT_ERRORS) == FAILURE)
{
php_stream_close(stream);
if (opened_path *opened_path)
efree(*opened_path);
return NULL;
}
We have already stat()'ed the file to death. We know it is there, that we
are allowed to open it, etc. What could go wrong that the open call just
above it wouldn't have caught? Is it just a case of getting too general
and we need a special-case simpler function for the most common operation
of simply opening script files?
-Rasmus
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Performance degradation
So, I am just starting out down the path to figure out why PHP 4.3 has gotten so much slower than 4.2. strace -c provides the first clue. A straight ./configure --enable-inline-optimization make command-line build for 4.2, 4.3 and 5.0 run on a simple hello world script reveals that we have gone from 219 system calls in 4.2 to 233 in 4.3 to 236 in 5.0. This is a bad trend and we really need to make an effort to reverse this. 4.2 Hello World from command-line: % time seconds usecs/call callserrors syscall -- --- --- - - 21.860.000266 1617 3 open 19.060.000232 29 8 write 15.690.000191 1118 read 12.570.000153 285 brk 10.440.000127 524 old_mmap 4.110.50 10 5 munmap 3.370.41 7 6 mmap2 2.960.36 5 8 mprotect 2.550.31 215 fstat64 2.380.29 214 close 0.740.09 5 2 lstat64 0.660.08 4 2 rt_sigaction 0.660.08 8 1 getcwd 0.490.06 3 2 2 ioctl 0.490.06 6 1 uname 0.410.05 3 2 setitimer 0.410.05 3 2 fcntl64 0.330.04 4 1 chdir 0.250.03 2 2 getpid 0.250.03 3 1 _llseek 0.160.02 2 1 time 0.080.01 1 1 gettimeofday 0.080.01 1 1 rt_sigprocmask -- --- --- - - 100.000.001217 219 5 total 4.3 Hello World from command-line: % time seconds usecs/call callserrors syscall -- --- --- - - 21.550.000292 1520 7 open 18.300.000248 28 9 write 14.610.000198 1217 read 13.060.000177 295 brk 8.340.000113 522 old_mmap 6.350.86 22 4 lstat64 3.690.50 10 5 munmap 3.030.41 7 6 mmap2 2.580.35 5 7 mprotect 2.360.32 214 fstat64 2.210.30 213 close 0.590.08 2 4 setitimer 0.590.08 3 3 rt_sigaction 0.590.08 8 1 getcwd 0.370.05 5 1 chdir 0.370.05 5 1 uname 0.300.04 2 2 2 ioctl 0.300.04 2 2 fcntl64 0.220.03 2 2 getpid 0.150.02 2 1 time 0.150.02 2 1 gettimeofday 0.150.02 2 1 _llseek 0.150.02 1 2 rt_sigprocmask -- --- --- - - 100.000.001355 233 9 total 5.0 Hello World from command-line: % time seconds usecs/call callserrors syscall -- --- --- - - 21.700.000288 1420 7 open 18.990.000252 28 9 write 15.070.000200 297 brk 14.920.000198 1217 read 8.290.000110 522 old_mmap 5.430.72 12 6 munmap 3.540.47 7 7 mmap2 2.490.33 5 7 mprotect 2.190.29 213 close 2.030.27 214 fstat64 1.430.19 5 4 lstat64 0.680.09 3 3 rt_sigaction 0.600.08 2 4 setitimer 0.600.08 8 1 getcwd 0.380.05 5 1 uname 0.300.04 4 1 chdir 0.300.04 2 2 fcntl64 0.230.03 2 2 getpid 0.230.03 3 1 1 ioctl 0.230.03
Re: [PHP-DEV] Performance degradation
So, obviously these opens don't really affect the module version since they only happen on startup, but they still don't seem right. I understand ./php-cgi.ini, but .//php-cgi.ini and .//php.ini? Looks like a missing check there. I just recognized these yesturday, too and was thinking the same. marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Performance degradation
RL So, obviously these opens don't really affect the module version RL since they only happen on startup, but they still don't seem right. RL I understand ./php-cgi.ini, but .//php-cgi.ini and .//php.ini? RL Looks like a missing check there. If this is only for CGI/startup, it is indeed not so important, IMHO. After all, CGI is not a performance-star anyway. RL Anybody know what the increase from 85 to 95 brk calls actually tells us? Either increased memory usage or substantial change in memory usage pattern (e.g., allocation of one big object, than freeing and allocation a number of small objects with the same size should generate less brk's then allocating small ones first and then large one). -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.109 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Performance degradation
On Sun, 23 Feb 2003, Stanislav Malyshev wrote: RL So, obviously these opens don't really affect the module version RL since they only happen on startup, but they still don't seem right. RL I understand ./php-cgi.ini, but .//php-cgi.ini and .//php.ini? RL Looks like a missing check there. If this is only for CGI/startup, it is indeed not so important, IMHO. After all, CGI is not a performance-star anyway. True, but that doesn't mean we should be doing stupid things like trying to open the same file twice or calling realpath() twice on the same path. And obviously something similar is happening to the module case because we are 10-15% slower in the module version. Either increased memory usage or substantial change in memory usage pattern (e.g., allocation of one big object, than freeing and allocation a number of small objects with the same size should generate less brk's then allocating small ones first and then large one). The script I tested was simply: html body ? echo Hello World; ? /body /html Hopefully executing this should not have caused a big change in memory usage between 4.2 and 4.3. -Rasmus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Performance degradation part 2 the module version
A little bit harder to get clean output on this one. The numbers in the
's are the times for the system call. Here is a 4.2 hello world
request:
accept(24, {sin_family=AF_INET, sin_port=htons(57198),
sin_addr=inet_addr(10.0.1.254)}}, [16]) = 3 4.035087
rt_sigaction(SIGUSR1, {SIG_IGN}, {0x40035250, [], SA_INTERRUPT|0x400}, 8) = 0
0.09
getsockname(3, {sin_family=AF_INET, sin_port=htons(80),
sin_addr=inet_addr(10.0.1.253)}}, [16]) = 0 0.09
setsockopt(3, SOL_TCP, TCP_NODELAY, [1], 4) = 0 0.11
alarm(300) = 0 0.10
read(3, GET /index.php HTTP/1.0\r\nUser-Ag..., 4096) = 106 0.18
rt_sigaction(SIGUSR1, {SIG_IGN}, {SIG_IGN}, 8) = 0 0.08
time(NULL) = 1046024055 0.08
alarm(300) = 300 0.09
alarm(0)= 300 0.08
stat64(/html/index.php, {st_mode=S_IFREG|0644, st_size=58, ...}) = 0 0.23
alarm(300) = 0 0.09
umask(077) = 022 0.07
umask(022) = 077 0.08
setitimer(ITIMER_PROF, {it_interval={0, 0}, it_value={30, 0}}, NULL) = 0 0.08
rt_sigaction(SIGPROF, {0x40690508, [PROF], SA_RESTART|0x400}, {0x40690508, [PROF],
SA_RESTART|0x400}, 8) = 0 0.08
rt_sigprocmask(SIG_UNBLOCK, [PROF], NULL, 8) = 0 0.08
getcwd(/usr/sbin, 4095) = 10 0.12
chdir(/html) = 0 0.14
open(/html/index.php, O_RDONLY) = 4 0.19
getcwd(/html, 4095) = 6 0.09
lstat64(/html, {st_mode=S_IFDIR|0777, st_size=4096, ...}) = 0 0.12
lstat64(/html/index.php, {st_mode=S_IFREG|0644, st_size=58, ...}) = 0 0.11
ioctl(4, SNDCTL_TMR_TIMEBASE, 0xbfffe1a0) = -1 ENOTTY (Inappropriate ioctl for device)
0.09
fstat64(4, {st_mode=S_IFREG|0644, st_size=58, ...}) = 0 0.08
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x402ba000
0.27
read(4, html\nbody\n?\n\techo \Hello Wo..., 8192) = 58 0.15
read(4, , 4096) = 0 0.08
read(4, , 8192) = 0 0.08
ioctl(4, SNDCTL_TMR_TIMEBASE, 0xbfffd160) = -1 ENOTTY (Inappropriate ioctl for device)
0.08
close(4)= 0 0.10
munmap(0x402ba000, 4096)= 0 0.13
alarm(300) = 300 0.09
alarm(0)= 300 0.08
chdir(/usr/sbin) = 0 0.19
setitimer(ITIMER_PROF, {it_interval={0, 0}, it_value={0, 0}}, NULL) = 0 0.09
umask(022) = 022 0.07
alarm(0)= 0 0.08
select(4, [3], NULL, NULL, {0, 0}) = 0 (Timeout) 0.10
write(3, HTTP/1.1 200 OK\r\nDate: Sun, 23 F..., 232) = 232 0.34
time(NULL) = 1046024055 0.08
write(39, 10.0.1.254 - - [23/Feb/2003:10:1..., 94) = 94 0.24
alarm(30) = 0 0.09
shutdown(3, 1 /* send */) = 0 0.24
select(4, [3], NULL, NULL, {2, 0}) = 1 (in [3], left {2, 0}) 0.000775
read(3, , 512)= 0 0.14
close(3)= 0 0.27
alarm(0)= 30 0.08
rt_sigaction(SIGUSR1, {0x40035250, [], SA_INTERRUPT|0x400}, {SIG_IGN}, 8) = 0
0.09
alarm(0)= 0 0.08
This is just from accept-to-accept, so it doesn't include any Apache/PHP
startup calls at all. A couple of these syscalls are from Apache but
starting with the alarm(300) call (I think) we are in PHP. The only thing
that looks slightly off to me in this set of calls are the consecutive
umask() calls. Might be something worth tracking down to see if one can
be eliminated. The point here however is to compare to 4.3:
accept(24, {sin_family=AF_INET, sin_port=htons(57262),
sin_addr=inet_addr(10.0.1.254)}}, [16]) = 3 8.485988
rt_sigaction(SIGUSR1, {SIG_IGN}, {0x40035250, [], SA_INTERRUPT|0x400}, 8) = 0
0.09
getsockname(3, {sin_family=AF_INET, sin_port=htons(80),
sin_addr=inet_addr(10.0.1.253)}}, [16]) = 0 0.10
setsockopt(3, SOL_TCP, TCP_NODELAY, [1], 4) = 0 0.12
alarm(300) = 0 0.10
read(3, GET /index.php HTTP/1.0\r\nUser-Ag..., 4096) = 106 0.16
rt_sigaction(SIGUSR1, {SIG_IGN}, {SIG_IGN}, 8) = 0 0.08
time(NULL) = 1046024677 0.08
alarm(300) = 300 0.08
alarm(0)= 300 0.08
stat64(/html/index.php, {st_mode=S_IFREG|0644, st_size=58, ...}) = 0 0.22
alarm(300) = 0 0.09
umask(077) = 022 0.08
umask(022) = 077 0.07
setitimer(ITIMER_PROF, {it_interval={0, 0}, it_value={30, 0}}, NULL) = 0 0.09
rt_sigaction(SIGPROF, {0x4072d6b4, [PROF], SA_RESTART|0x400}, {0x4072d6b4,
Re: [PHP-DEV] Performance degradation part 2 the module version
Rasmus Lerdorf wrote: Even in 4.2, I think we can optimize it. Assuming chdir() doesn't return an error, we shouldn't need that second getpwd() call since we just did the chdir() and we should know where we are. Not necessarily... In a threaded environment, if threadA does chdir(/tmp) and then threadB does chdir(/var), then the actual process is in /var for the remainder of threadA (IIRC). chdir() is process scoped. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Performance degradation part 2 the module version
On Sun, 23 Feb 2003, Jim Jagielski wrote: Rasmus Lerdorf wrote: Even in 4.2, I think we can optimize it. Assuming chdir() doesn't return an error, we shouldn't need that second getpwd() call since we just did the chdir() and we should know where we are. Not necessarily... In a threaded environment, if threadA does chdir(/tmp) and then threadB does chdir(/var), then the actual process is in /var for the remainder of threadA (IIRC). chdir() is process scoped. That's true, but in threaded mode we don't do the chdir() at all. This is specifically for non-threaded. -Rasmus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Performance degradation part 2 the module version
Rasmus Lerdorf wrote: That's true, but in threaded mode we don't do the chdir() at all. This is specifically for non-threaded. Gotcha... didn't realize you were referring to non-t'ed only. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Performance degradation
Rasmus Lerdorf wrote: So, I am just starting out down the path to figure out why PHP 4.3 has gotten so much slower than 4.2. strace -c provides the first clue. A straight ./configure --enable-inline-optimization make command-line build for 4.2, 4.3 and 5.0 run on a simple hello world script reveals that we have gone from 219 system calls in 4.2 to 233 in 4.3 to 236 in 5.0. This is a bad trend and we really need to make an effort to reverse this. 4.2 Hello World from command-line: CGI, right? Part of this may be from the path_info handling I've added. There is a stat call in there to determine if the path provided by the webserver includes path_info also, if it does have path_info (stat failed), it walks up the path doing a stat to determine the script filename and path_info correctly. the ini setting cgi.fix_pathinfo turns this on or off. It also uses a handfull putenv and getenv calls in straightening things out. I'm sure this adds some of that, but I don't think it would add as much an increase as you are seeing, unless you're using some long path_info paths. Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Performance degradation
On Sun, 23 Feb 2003, Shane Caraveo wrote: Rasmus Lerdorf wrote: So, I am just starting out down the path to figure out why PHP 4.3 has gotten so much slower than 4.2. strace -c provides the first clue. A straight ./configure --enable-inline-optimization make command-line build for 4.2, 4.3 and 5.0 run on a simple hello world script reveals that we have gone from 219 system calls in 4.2 to 233 in 4.3 to 236 in 5.0. This is a bad trend and we really need to make an effort to reverse this. 4.2 Hello World from command-line: CGI, right? Part of this may be from the path_info handling I've added. There is a stat call in there to determine if the path provided by the webserver includes path_info also, if it does have path_info (stat failed), it walks up the path doing a stat to determine the script filename and path_info correctly. the ini setting cgi.fix_pathinfo turns this on or off. It also uses a handfull putenv and getenv calls in straightening things out. I'm sure this adds some of that, but I don't think it would add as much an increase as you are seeing, unless you're using some long path_info paths. The extra realpath() and fstat() calls are not cgi specific, so if what you added only affects cgi, then that isn't the big problem. -Rasmus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Performance degradation
Rasmus Lerdorf wrote: On Sun, 23 Feb 2003, Shane Caraveo wrote: CGI, right? Part of this may be from the path_info handling I've added. The extra realpath() and fstat() calls are not cgi specific, so if what you added only affects cgi, then that isn't the big problem. -Rasmus ok, it's only in CGI. Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Performance degradation part 2 the module version
This double seeking is most probably due to the fact that the stdio layer does one set of seeking, whereas streams needs to do another. This can be solved by moving away from using stdio for streams, and just using the raw descriptors instead. (already made a start on this in PHP 5). I'm a little unsure if we should apply equivalent changes to the branch (given our release policy), but I share your concerns for performance. Ilia and I have discussed implementing some kind of fstat cache for use by the plain file streams. However, we are nowhere near implementing this, yet alone certifying it safe for inclusion in the branch. Have you been testing PHP_4_3 from CVS or the actual 4.3.0 release? You might find the situation slightly better using the latest (I tidied up some seek related issues the other day). --Wez. On Sun, 23 Feb 2003, Rasmus Lerdorf wrote: In 4.3 we have: _llseek(4, 0, [0], SEEK_CUR)= 0 0.09 lseek(4, 0, SEEK_SET) = 0 0.09 brk(0) = 0x81a8000 0.08 brk(0x81a9000) = 0x81a9000 0.11 ioctl(4, SNDCTL_TMR_TIMEBASE, 0xbfffd190) = -1 ENOTTY (Inappropriate ioctl for device) 0.09 brk(0) = 0x81a9000 0.07 brk(0x81aa000) = 0x81aa000 0.09 read(4, html\nbody\n?\n\techo \Hello Wo..., 8192) = 58 0.16 read(4, , 4096) = 0 0.08 read(4, , 8192) = 0 0.09 ioctl(4, SNDCTL_TMR_TIMEBASE, 0xbfffc150) = -1 ENOTTY (Inappropriate ioctl for device) 0.08 close(4)= 0 0.10 munmap(0x402ba000, 4096)= 0 0.14 I really don't understand the SEEK_CUR there. We're seeking forward 0 bytes from the current location followed directly by a SEEK_SET back to 0? Is this streams overhead or something? Wez? From there on the requests are similar. The alarm(0) calls right after alarm(300) could probably be skipped in both cases. Anyway, I will go after all these extra lstat/fstat calls and fix that, but I would appreciate some help with the setitimer() and weird seeking stuff. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Performance degradation part 2 the module version
Have you been testing PHP_4_3 from CVS or the actual 4.3.0 release? You might find the situation slightly better using the latest (I tidied up some seek related issues the other day). The straces are from PHP_4_3 HEAD as of this morning. I thought originally that these issues were just a hassle for me at Yahoo! where performance is super-critical and that the average PHP user wouldn't really care. But I am seeing normal users switching back to 4.2 from 4.3 now because of these issues. We can probably live with the seek overhead if I can get rid of the rest. If I can eliminate that one getcwd() call that was also in 4.2, perhaps we can get back to being on par. -Rasmus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
