Prev: Dear Lazy Web: Pseudo Randomisation Strategies on Listing Websites
Next: Dear Lazy Web: Pseudo Randomisation Strategies onListing Websites
From: =?UTF-8?B?U3RhbmlzxYJhdyBGaW5kZWlzZW4=?= on 20 Aug 2010 08:11 Hi Could anyone please explain to me the basic architecture of PHP module when running "in process" within Apache HTTP server? I guess this is called "mod_php". As far as I understand the shared library (e.g., libphp5.so) is being dynamically loaded by an Apache working process and then, whenever a ..php (or .php3, or...) file is requested the working process calls the PHP interpreter. This call to the PHP interpreter is a function call and there is no fork(2) nor execve(2) in play at all. Is this correct? STF http://eisenbits.homelinux.net/~stf/ OpenPGP: DFD9 0146 3794 9CF6 17EA D63F DBF5 8AA8 3B31 FE8A
From: Bostjan Skufca on 20 Aug 2010 11:10 Yes, this is correct. If you look at sapi/apache2handler/sapi_apache2.c in PHP sources, you will find that PHP SAPI registers it's function php_handler() within apache. This function gets called every time PHP is requested by some client (with appropriate configuration, of course). I must admit that PHP-DEV (INTERNALS) seems more appropriate list for such question :) b. 2010/8/20 StanisÅaw Findeisen <stf(a)eisenbits.homelinux.net> > Hi > > Could anyone please explain to me the basic architecture of PHP module > when running "in process" within Apache HTTP server? > I guess this is called "mod_php". > > As far as I understand the shared library (e.g., libphp5.so) is being > dynamically loaded by an Apache working process and then, whenever a > .php (or .php3, or...) file is requested the working process calls the > PHP interpreter. This call to the PHP interpreter is a function call and > there is no fork(2) nor execve(2) in play at all. > > Is this correct? > > STF > > http://eisenbits.homelinux.net/~stf/<http://eisenbits.homelinux.net/%7Estf/> > OpenPGP: DFD9 0146 3794 9CF6 17EA D63F DBF5 8AA8 3B31 FE8A > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > >
From: =?UTF-8?B?U3RhbmlzxYJhdyBGaW5kZWlzZW4=?= on 20 Aug 2010 14:15 On 2010-08-20 17:10, Bostjan Skufca wrote: > Yes, this is correct. > > If you look at sapi/apache2handler/sapi_apache2.c in PHP sources, you will > find that PHP SAPI registers it's function php_handler() within apache. This > function gets called every time PHP is requested by some client (with > appropriate configuration, of course). > > I must admit that PHP-DEV (INTERNALS) seems more appropriate list for such > question :) 1. What optimizations does PHP interpreter make? I guess it should be able to check file modification time and cease to compile it again and again. Is this correct? There is some bytecode form, right? What else does it do? For instance if there is a big, immutable class in the application (say it contains a bunch of constant XML documents, hardcoded into the source): will the interpreter notice that and instantiate this class only once across multiple requests? What if this class generates side effects (like printing "hello world" in the constructor) and what if it doesn't? 2. I guess PHP application wide cache is quite a different story? For the worker processes are separate... Or maybe PHP interpreter itself provides any means for that?? 3. Does PHP interpreter maintain any state across different requests within the context of a single Apache worker process? If so, what does this state contain? 4. Does PHP interpreter maintain any global state within the context of a single Apache HTTP server instance? If so, what does this state contain? 5. What about system wide PHP interpreter state?... 6. I heard some nasty rumors that PHP interpreter resource management is somewhat problematic (memory leaks, or something), and because of that those Apache worker processes have to be killed from time to time. Could you please comment on this? > 2010/8/20 Stanisław Findeisen <stf(a)eisenbits.homelinux.net> > >> Hi >> >> Could anyone please explain to me the basic architecture of PHP module >> when running "in process" within Apache HTTP server? >> I guess this is called "mod_php". >> >> As far as I understand the shared library (e.g., libphp5.so) is being >> dynamically loaded by an Apache working process and then, whenever a >> .php (or .php3, or...) file is requested the working process calls the >> PHP interpreter. This call to the PHP interpreter is a function call and >> there is no fork(2) nor execve(2) in play at all. >> >> Is this correct? STF http://eisenbits.homelinux.net/~stf/ OpenPGP: DFD9 0146 3794 9CF6 17EA D63F DBF5 8AA8 3B31 FE8A
From: Guillaume Rossolini on 20 Aug 2010 16:59
Hi, 1. What optimizations does PHP interpreter make? I guess it should be > able to check file modification time and cease to compile it again and > again. Is this correct? > > There is some bytecode form, right? > Core PHP does not optimize your code like a DBMS would rewrite your SQL. There are however extensions that can do that kind of post processing (APC, XCache, etc.). > What else does it do? For instance if there is a big, immutable class in > the application (say it contains a bunch of constant XML documents, > hardcoded into the source): will the interpreter notice that and > instantiate this class only once across multiple requests? > > What if this class generates side effects (like printing "hello world" > in the constructor) and what if it doesn't? > Fortunately, it does not notice that. Remember that PHP is a dynamic language by nature and that, given the right extension(s), even class definitions can be altered at runtime. It would be a mess to use those functionalities if PHP itself compiled the code. > 2. I guess PHP application wide cache is quite a different story? For > the worker processes are separate... Or maybe PHP interpreter itself > provides any means for that?? > Yes, it is a different story indeed. Often, application wide caches are application specific, and not only their configuration.There is userland code for this on the Web. Basically, that's the kind of functionality frameworks provide, so by choosing a framework you get their caching techniques. Depending on the application, you could rely on your web server (httpd or whatever) to do that. Of course, you could also use output caching with PHP (look for ob_start in the manual). > 3. Does PHP interpreter maintain any state across different requests > within the context of a single Apache worker process? If so, what does > this state contain? > I would suggest you read the "sessions" section of the manual or that you split your questions to php-general and internals. The internals list is not suited for this discussion. 4. Does PHP interpreter maintain any global state within the context of > a single Apache HTTP server instance? If so, what does this state contain? I don't think there is such a state ready for userland code to read, but I also don't think you really need it. You can read a few things like the total memory usage for your script, as well as some apache-related functions (quite well documented, feel free to read the docs) and that's about it. That's more than most web applications need (production-wise), at any rate. > 5. What about system wide PHP interpreter state?... > PHP depends on a SAPI, it is not hosted directly by the system. Its memory is part of the memory allocated to the server. When a segfault happens, I guess it kills both the script and the thread running it, then the server spawns another thread running PHP and life goes on. The logs have what you need. > 6. I heard some nasty rumors that PHP interpreter resource management is > somewhat problematic (memory leaks, or something), and because of that > those Apache worker processes have to be killed from time to time. > PHP is dynamically typed. From a memory perspective, it is a language with kind of managed types (my choice of words may not be optimal here). It even comes with a garbage collector from 5.3 onwards though memory management a la C is not what PHP is used for. But yes, if you abuse the easy variable declaring and copying PHP provides, you will end up eating your memory as you would with anything else. You could kill processes or use a CGI-derived SAPI. Apache httpd is not the only web server out there. Most of the time, memory leaks that make you restart apache workers are application-level leaks, not PHP's fault. When found, memory leaks in PHP are bugs and bugs get fixed, so in the long run there are no more memory leaks in PHP than in other systems. Again, internals is not suited for this talk unless you have a very specific patch or RFC to discuss. Regards, -- Guillaume Rossolini |