From: =?UTF-8?B?U3RhbmlzxYJhdyBGaW5kZWlzZW4=?= on
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
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
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
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