Thanks for all the comments to my “Application Server in PHP? well… Yes!” posting. I was really amazed to see that many interested people. Your support gives me a great motivation. Thanks, guys! 
I am currently thinking about proper object hierarchy and, actually, I changed it completely 3 times already in my thoughts. I finally “see the light”â„¢ and will implement it on a weekend. I think about converting SCGI-part to a simple “driver” and move all http-related stuff to a separate driver-agnostic set of classes (Probably, that would be a class per kind of http-request and a class per kind of http-response). This way, I would be able to implement FastCGI as anther driver without altering applications. If you have any better ideas — let me know.
For now, I made another example application. This time, with some benchmarking in thoughts. Here it is.
This example supposes, that you have ezcomponents folder on the one level with the svn-checked-out “trunk” of my googlecode-project. And, you can start “runner.php” both as SCGI-server (using CLI) or as usual mod_php/(fast)cgi application. The idea was to see if there will be any noticeable speed difference between approaches. But… it showed the other thing
I used ezcGraph in my application and noticed a serious memory-leaking. Obviously, ezcGraph has the forementioned in comments problem with cycled references. The solution is, to add some kind of “public function clean()” method, which would remove references in the object, and objects which were auto-generated by it, so it would later be cleaned-up by a garbage-collector. I implemented a quick-fix locally and it did help to some degreee, but I definitely missed some references, so it still leaked. I think that someone who knows internals of eZComponents better should do it.
Derick? Anyone? Can this be done?
I am happy, that you are using ezcGraph for your tests, but the problem you mention is one of the major causes, why PHP does not (yet) work very well as an (application) server. PHP was never designed to run longer then responding to one request and therefore does not care that much about memory cleanup. Freeing cyclic references is up to the engine and (imho) should not be addressed in an component / application itself.
You may want to have a look as the GSoC project to cleanup cyclic references in PHP, mentored by Derick, which most probably will fix this for you.
For now you of course have a problem here, but I would expect, that you get this with nearly each object orientated application / component you may use.
Alexey Zakhlestin’s Blog: PHP+SCGI part 2: problem with eZComponents…
…
kore:
Well, actually, in my own “framework” I don’t have any cyclic references and all of the Singletones have manual “destructors”… And it doesn’t add much complexity
So, it can be done (and leads to a very clean component-relations structure)
Though, I definitely wait for results of that GCoC project
[...] Outro post do autor: http://blog.milkfarmsoft.com/?p=52 [...]
that is nice