Re: reducing open calls in php
| From: | Rasmus Lerdorf | Date: | Wed, 01 Feb 2006 20:04:12 +0000 |
| Subject: | Re: reducing open calls in php | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-21754@lists.php.net to get a copy of this message | ||
I think the main hint you need is to never use require_once/include_once with an opcode cache. Those are the only ones that will cause an open() call. You should only be seeing a single stat() call per file under APC (needed to get the inode+device hash key for the shared memory lookup).
-Rasmus
James M Luedke wrote:
Hello:We have a very high-volume site that runs across a cluster of severalmachines which needs to have access to our back end storage platform, which needless to say is very busy. I have been given the task of reducing load to the filer. Due to the fact that our application is rather large and includes lots of files which reside on our filer, php would be a good place to cut down load.We currently have a rather unique setup. We are running php withfast-cgi support via sapi/cgi/cgi_main.c as well as APC for opcode/user caching**. This allows us to run php as a daemon which reduces system calls and retains persistence with APC. Our setup has been working quite well. However, there is one behavior that is less than optimal.Whenever one of our pages is accessed, it appears*** that the requestedfile and all included files are opened, which results in several open calls to our filer. As I mentioned, we are running APC which seems to be doing a nice job of op-code caching. It would be ideal if somehow I could modify php to first check APC cache for the pre-compiled opcode before attempting to open the file. This would be a huge win on our cluster, since each hit currently generates 5-10 open calls.Now please bear with me because I am new to the Zend / main tree of the php source. If my understanding is correct, the basic flow of cgi/php goes something like this:request some variable init. module_init <-apc overide compile_file w/my_compile_file php_fopen_primary_script(&file_handle TSRMLS_CC); php_execute_script(&file_handle TSRMLS_CC);VCWD_CHDIR_FILE(primary_file->filename); # i think included_files gets opened here someplace # i do not understand that magic yet. zend_execute_scripts() zend_compile_file() compile_file || my_compile_file() <-- apc # it looks like the std compile_file # may do some zend_open cmds here via # open_file_for_scaning() zend_destroy_file_handle() <-- destroy before execute? zend_execute() php_request_shutdown() FCGX_Finish_r;I have a few questions: 1. When exactly do the files get opened/read? And is this a necessary step if you already have the op-code. 2. Is it possible to check apc_cache before opening files? If it is possible, how/where do you think it could be best implemented? Is there some similar interface to the my_compile_file trick used to override zend_compile_file by apc? Perhaps something like my_open_file, which I could then add support for into the apc module? 3. would changing utility_functions->fopen_function; to point to my_fopen_function in place of zend_open work. Any input would be greatly appreciated. -James ** ( mod_php and the likes are not an option for us as we have our own custom web server which we cannot do without :) ) *** when i truss one of the php daemon process i can clearly see that it opens and reads the requested file. It also opens all the included/required files but does not seem read them.