Theese days I’ve been following a thread in the php-es mailing list at lists.php.es. A subscriber noticed that static class attributes weren’t shared between different page requests. Someone explained him that the way PHP deals with the requests is the cause for it not to have an “application” variable scope.
In Java servlets, for example, static class attributes are shared by all the instances of that class in the virtual machine. Scalability (and speed) at a medium scale is achieved using object in-memory caches. In PHP that approach can’t be done without using shared memory management libraries, and never in an easy way. Developers have to resort to disk and database caches, much slower that the memory ones.
Moreover, the fact of having to parse in each request not only the target PHP file, but also all those ones recursively included, represent another of the disadvantages of the platform.
It’s strange because, as far as I know, an “execution environment” common to all the requests does exist on other languages, like Perl (Apache mod_perl) or Python. That way, data can be shared among the requests, memory caches can be done, and so on.
Something that would be nice, even being a daydream, would be to develop an “application server” consisting of:
- A library that made shared memory usage simpler for storing session variables and object instances on it (even singletons), making them available from different threads.
- A multithreaded web server implemented entirely in PHP using the socket API. The server would spawn threads with each request using the threads and processes API. It’d be a replacement for Apache.
This way, we would have the advanteges of the application servers and the syntax simplicity of PHP. The disadvantage would be that, as PHP has been developed with the “parse, create environment, process the request and dispose everything” model in mind, with the proposed approach, a great number of memory leaks would be found. That memory leaks are currently hidden thanks to the short life cycle of the requests.
That’s all. This was an idea I had some time ago and it seemed interesting to me. Now I’ve decided to share it with you. It’s surprising that nobody has already thought about it, isn’t it?
UPDATE:
I’ve just found Quercus, a PHP5 implementation written in Java that allows PHP programs to interact directly with Java libraries, taking advantage of all the benefits that Java caches, connection pools, etc. can provide. It’s not the same approach I propose, but maybe a good one anyway.