I am currently thinking about proper object hierarchy and, actually, I changed it completely 3 times already in my thoughts. I finally . . . → Read More: PHP+SCGI part 2: problem with eZComponents]]> 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?