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

> 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.


Guillaume Rossolini

Reply via email to