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
