Re: [PHP-DEV] mod_php4 question...

[Andi Gutmans]

We actually use the getcwd() result in order to support good error messages 
and include_once() and friends. It's a bit sucky that getcwd() is so slow 
on Solaris. On Linux it's extremely fast because it doesn't do a million 
chdir(..).
I'm not that enthusiastic about changing the current behavior.
Andi

At 06:01 PM 9/25/2001 -0600, Andy Sautins wrote:

>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 
>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 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] mod_php4 question...

[Andy Sautins]

   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 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]