[PHP-DEV] mod_php4 question...
I posted a previous message that, I must admit, was probably not that well thought out. I've looked a little further and I'm getting a better feel for what is going on, but I was wondering if someone in the know would be able to clarify. I'm using php with Apache. When I truss a simple file, I see the majority of the system calls in stat calls. It tracks down to a getcwd ( defined with VCWD_GETCWD ), which seems to do alot of I/O on solaris. Given that on a heavily loaded box, avoid that much I/O ( especially if it is just checking the same filepath that was checked previously), seems wasteful and can lead to high I/O waits. The call stack is something along the lines of: 1 send_php 2 zend_execute_scripts 3 zend_compile_file 4 complie_file 5 open_file_for_scanning 6 zend_fopen 7 php_fopen_wrapper_for_zend 8 php_fopen_wrapper 9 php_fopen_url_wrapper 10 php_fopen_with_path 11 php_fopen_and_set_opened_path 12 expand_filepath 13 vcwd_getcwd It seems to me that the path is available from apache ( either through the request structure or as part of the filename ). My question is, what would be the harm in doing something like have mod_php4.c open the file and set file_handle-handle.fp and close it ( or some other mechanism from having to call the whole php_fopen_and_set_opened_path ) to avoid the getcwd? Any thoughts? I'll do some more testing, but I wanted to get some expert feedback before I went too far down the wrong path. Thanks Andy -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Question about php_fopen_and_set_opened_path...
Not 100% sure what my question is here, but I'm curious.
A little while back I was running PHP-4.0.6 on Solaris8 using apache and
wanted to get an idea of expect performance and configuration issues ( was
mostly curious about my apache configuration to make sure the .htaccess
calls were removed ). I ran a perl script to hit the following script:
? print Test; ?
I trussed an apache/php httpd process and was a little suprised by the
results.
There is a string of open/fstat/getdents64/close calls that are the majority
of the
system activity for the above simple example and I'm assuming is the
majority of
the I/O wait under load.
I think I traced it down to a call to expand_filepath in
php_fopen_and_set_opened_path.
Not sure why this is done or what it is for. Could someone please enlighten
me? It is my
belief that if it could be minimized that it could significantly reduce
system load for simple
php scripts.
Thanks. Hope this makes sense. What follows is the truss for a single
HTTP Get to
the above simple script:
umask(077) = 022
umask(022) = 077
setitimer(ITIMER_PROF, 0xFFBEF520, 0x) = 0
sigaction(SIGPROF, 0xFFBEF3F0, 0xFFBEF470) = 0
sigprocmask(SIG_UNBLOCK, 0xFFBEF510, 0x) = 0
pathconf(., _PC_PATH_MAX) = 1024
stat64(./, 0xFFBEE408) = 0
stat64(/, 0xFFBEE370) = 0
open64(./../, O_RDONLY|O_NDELAY) = 5
fcntl(5, F_SETFD, 0x0001) = 0
fstat64(5, 0xFFBECD90) = 0
fstat64(5, 0xFFBEE408) = 0
close(5) = 0
chdir(/local/home/usr/local/apache/htdocs) = 0
open(/local/home/usr/local/apache/htdocs/f.php, O_RDONLY) = 5
pathconf(., _PC_PATH_MAX) = 1024
stat64(./, 0xFFBED730) = 0
stat64(/, 0xFFBED698) = 0
open64(./../, O_RDONLY|O_NDELAY) = 6
fcntl(6, F_SETFD, 0x0001) = 0
fstat64(6, 0xFFBECCB8) = 0
fstat64(6, 0xFFBED730) = 0
getdents64(6, 0x0016A538, 1048) = 320
close(6) = 0
open64(./../../, O_RDONLY|O_NDELAY) = 6
fcntl(6, F_SETFD, 0x0001) = 0
fstat64(6, 0xFFBECCB8) = 0
fstat64(6, 0xFFBED730) = 0
getdents64(6, 0x0016A538, 1048) = 144
close(6) = 0
open64(./../../../, O_RDONLY|O_NDELAY) = 6
fcntl(6, F_SETFD, 0x0001) = 0
fstat64(6, 0xFFBECCB8) = 0
fstat64(6, 0xFFBED730) = 0
getdents64(6, 0x0016A538, 1048) = 648
close(6) = 0
open64(./../../../../, O_RDONLY|O_NDELAY) = 6
fcntl(6, F_SETFD, 0x0001) = 0
fstat64(6, 0xFFBECCB8) = 0
fstat64(6, 0xFFBED730) = 0
getdents64(6, 0x0016A538, 1048) = 208
close(6) = 0
open64(./../../../../../, O_RDONLY|O_NDELAY) = 6
fcntl(6, F_SETFD, 0x0001) = 0
fstat64(6, 0xFFBECCB8) = 0
fstat64(6, 0xFFBED730) = 0
getdents64(6, 0x0016A538, 1048) = 432
close(6) = 0
open64(./../../../../../../, O_RDONLY|O_NDELAY) = 6
fcntl(6, F_SETFD, 0x0001) = 0
fstat64(6, 0xFFBECCB8) = 0
fstat64(6, 0xFFBED730) = 0
open(/etc/mnttab, O_RDONLY) = 7
fstat64(7, 0xFFBEC678) = 0
ioctl(7, TCGETA, 0xFFBEC604) Err#22 EINVAL
read(7, / d e v / d s k / c 0 t.., 512) = 455
ioctl(7, (('m'8)|1), 0xFF238BE0) = 0
ioctl(7, (('m'8)|2), 0x000BEA18) = 0
lstat64(/local, 0xFFBEC898) = 0
lstat64(/local/.., 0xFFBEC898) = 0
llseek(7, 0, SEEK_CUR) = 455
close(7) = 0
close(6) = 0
resolvepath(/local/home/usr/local/apache/htdocs/f.php,
/local/home/usr/local/apache/htdocs/f.php, 1024) = 46
ioctl(5, TCGETA, 0xFFBEE224) Err#25 ENOTTY
fstat64(5, 0xFFBECAB8) = 0
ioctl(5, TCGETA, 0xFFBECA44) Err#25 ENOTTY
read(5, ? p r i n t T e.., 8192) = 339
read(5, 0x001927B4, 8192) = 0
ioctl(5, TCGETA, 0xFFBECB1C) Err#25 ENOTTY
llseek(5, 0, SEEK_CUR) = 339
close(5) = 0
chdir(/) = 0
umask(022)
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] PHP 4.0 Bug #9876: OCIPLogon flaky after restart Oracle
I wouldn't exactly say the OCI interface has a bug. This is pretty
common behavior for
oracle drivers ( JDBC/ODBC drivers tend to do the same thing ). That's not
to say that is
an ideal situation ( It's nice to not have to bounce a server-farm when the
database goes
away ).
As I understand the driver ( and it's limited at this point ), OCIPLogon
returns back an
oracle connection from a pool ( a straight zend_hash_find in
oci_open_session ). It dosn't check to make sure that it is an active
connection
( which would require a round-trip to the database engine which would be
unnecessary the majority of the time ). The OCILogon gets around this by
opening a new
connection with the database each time ( which is considerably more
expensive ).
I don't have a great answer, but what you could/should do is to close the
session when you
receive a Oracle error of 03113 ( end of file on communcation channel ) or
03114 ( not connected
to oracle ) is to close the persistant connection. That will free the PHP
cached connection.
The code would be something like ( and I havent tested this ). Using
this would keep the
error from happening more than once.
function OCIExecuteWrapper($id,$stmt,$mode) {
@OCIExecute($stmt,$mode);
$err = OCIError($stmt);
if(($err != false ($err['code'] == 03113 || $err['code'] ==
03114)) {
trigger_error("Oracle Error: ". $err['code'] .
$err['message']);
OCILogoff($id);
}
return $err
}
The problem with pushing this kind of check into the OCI layer would be
that, if a connection
is lost your statements would be lost and need to be re-established (
including all bind variables ).
I don't see how this could be done automatically.
However, it does seem that automatically throwing away a know unconnected
session would be a pretty
interesting idea.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 20, 2001 9:56 AM
To: [EMAIL PROTECTED]
Subject: [PHP-DEV] PHP 4.0 Bug #9876: OCIPLogon flaky after restart
Oracle
From: [EMAIL PROTECTED]
Operating system: Redhat 6.1 Linux
PHP version: 4.0.4pl1
PHP Bug Type: OCI8 related
Bug description: OCIPLogon flaky after restart Oracle
./configure' '--prefix=/var/php' '--with-config-file-path=/var/php'
'--enable-track-vars'
'--enable-sigchild'
'--with-apache=../apache_1.3.14' '--with-ftp' '--with-xml'
'--with-mcrypt=/var/libmcrypt'
'--with-pgsql=/var/postgresql'
'--with-oci8=/u01/app/oracle/product/8.1.6' '--with-mysql=/var/mysql'
When using OCIPLogon for persistent connections, I'm noticing that after
restarting Oracle, that my PHP application starts getting Oracle
errors(ORA-03113 and ORA-03114). This can be fixed by restarting the
webserver after restarting Oracle. I also notice that changing my Oracle
connections from OCIPLogon to OCILogon fixes the problem - after making that
change I get no errors after restarting Oracle, and I *don't* have to
restart the webserver.
The OCI8 interface must have a bug, right? I shouldn't have to restart the
webserver after restarting Oracle just because I'm using persistent
connections, should I?
--
Edit Bug report at: http://bugs.php.net/?id=9876edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
