Disqus - Latest Comments for genabatyan

Re: Application Server in PHP? well… Yes!

genabatyan — Fri, 14 Aug 2009 12:57:01 -0000

Hey, thanks for fast reply!

Re: Application Server in PHP? well… Yes!

genabatyan — Fri, 14 Aug 2009 12:19:54 -0000

I think PHP is not an ideal thing for a process that:
- holds ONE connection with the webserver
- forks off it's own children and watches them in an intelligent way, so that their number matches the current load for instance
- bridge communication between every child and webserver connection (IMHO that's the worst part for doing in php)

What would be cool is a general SCGI multiplexer (ideally written in C or derivatives) that listens on a scgi port, forks off child processes and forwards all comunication between children and web server. Actually as far as I see it, this program does not have to know anything about SCGI protocol. To use your php app server without modification, the multiplexer could simply let every child start your runner.php listening on a different TCP port, immediately connect to this port and blindly relay communication with web server. Anyone knows of some general software capable of acomplishing such a thing? This is not classical tcp server, because tcp is used instead of IPC

BTW, just to be sure, do I see it right, that your php-app solution as it is - is only capable of processing all requests in a sequential order within one process, that is runner.php?

Re: FastCGI in PHP. The way it could be

genabatyan — Fri, 14 Aug 2009 11:03:48 -0000

Hey, I had the same Idea since ages. Today have been crawling the web if anyone has done anything this way.
It really surprises me that there's almost nothing on this topic and nobody seems to be interested!

Many sophisticated and resource-hungry PHP frameworks appear and become very popular, but come on, a test page of 5 lines, using doctrine to fetch one record from the database needs 50ms! and that's with APC enabled. This is absolutely ridiculous.
I believe if doctrine initialization - a great part of which is shared absolutely the same way across all requests - would be moved out of the fast-cgi request loop, performance boost would be gigantic and had a chance to get close to "normal" fast-cgi experiences.

I was trying to write a proof-of-concept almost zero-config pure-php solution to "long-living php workers" but without using any standards like fast-cgi. But it turned out to be too complex to waste time on it, why not doing it "right" from the beginning, that is implementing a widely accepted fastcgi protocol in pure PHP.

If you're still interested drop me a line!