mod_php4 question...
| From: | Andy Sautins | Date: | Wed, 26 Sep 2001 00:01:53 +0000 |
| Subject: | mod_php4 question... | ||
| Groups: | php.dev | ||
| Request: | Send a blank email to php-dev+get-66615@lists.php.net to get a copy of this message | ||
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