Comments on: FastCGI in PHP. The way it could be http://blog.milkfarmsoft.com/2006/06/fastcgi-in-php-the-way-it-could-be/ Programming for Mac and Web Thu, 04 Aug 2011 07:10:00 +0000 hourly 1 http://wordpress.org/?v=3.2.1 By: genabatyan http://blog.milkfarmsoft.com/2006/06/fastcgi-in-php-the-way-it-could-be/comment-page-1/#comment-80536 genabatyan Fri, 14 Aug 2009 20:03:48 +0000 http://blog.milkfarmsoft.com/?p=4#comment-80536 Hey, I had the same Idea since ages. Today have been crawling the web if anyone has done anything this way.<br>It really surprises me that there's almost nothing on this topic and nobody seems to be interested!<br><br>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.<br>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.<br><br>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.<br><br>If you're still interested drop me a line! 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!

]]> By: Сергей Куракин » Исследования Load Balancing и Performance для сайтов http://blog.milkfarmsoft.com/2006/06/fastcgi-in-php-the-way-it-could-be/comment-page-1/#comment-7677 Сергей Куракин » Исследования Load Balancing и Performance для сайтов Tue, 14 Aug 2007 15:10:29 +0000 http://blog.milkfarmsoft.com/?p=4#comment-7677 [...] Тяжело сказать, конечно, что всё это блоги и “добавлено в Google Reader”, просто всё это читалось, курилось, переваривалось: High Scalability - Building bigger, faster, more reliable websites. MySQL Performance Blog Domas Mituzas - специалист по MySQL + поддержка Wikipedia рекомендую Wikipedia: site internals, etc (the workbook) Load Balancing Your Web Site Performance Tuning Best Practices for MySQL MySQL Manual Index Hint Syntax Optimizing Queries with EXPLAIN FastCGI in PHP. The way it could be Lighttpd Performance Improvements Lighttpd Optimizing FastCGI performance Understanding FastCGI Application Performance Squid: Accelerator Mode XCache Faster Is Possible Using X-Accel-Redirect Header With Nginx to Implement Controlled Downloads Lighttpd X-Sendfile Scaling with MySQL replication Может чего и забыл - у меня нет лаптопа (я их ненавижу), поэтому часть ссылок ещё есть на другой машине, и возможно завтра я их тоже добавлю сюда. Blog, Web — Сергей Куракин @ 16:46 Уже комментировало (1) » [...] [...] Тяжело сказать, конечно, что всё это блоги и “добавлено в Google Reader”, просто всё это читалось, курилось, переваривалось: High Scalability – Building bigger, faster, more reliable websites. MySQL Performance Blog Domas Mituzas – специалист по MySQL + поддержка Wikipedia рекомендую Wikipedia: site internals, etc (the workbook) Load Balancing Your Web Site Performance Tuning Best Practices for MySQL MySQL Manual Index Hint Syntax Optimizing Queries with EXPLAIN FastCGI in PHP. The way it could be Lighttpd Performance Improvements Lighttpd Optimizing FastCGI performance Understanding FastCGI Application Performance Squid: Accelerator Mode XCache Faster Is Possible Using X-Accel-Redirect Header With Nginx to Implement Controlled Downloads Lighttpd X-Sendfile Scaling with MySQL replication Может чего и забыл – у меня нет лаптопа (я их ненавижу), поэтому часть ссылок ещё есть на другой машине, и возможно завтра я их тоже добавлю сюда. Blog, Web — Сергей Куракин @ 16:46 Уже комментировало (1) » [...]

]]> By: Alexey Zakhlestin’s blog » Application Server in PHP? well… Yes! http://blog.milkfarmsoft.com/2006/06/fastcgi-in-php-the-way-it-could-be/comment-page-1/#comment-5952 Alexey Zakhlestin’s blog » Application Server in PHP? well… Yes! Tue, 19 Jun 2007 13:06:21 +0000 http://blog.milkfarmsoft.com/?p=4#comment-5952 [...] Long story: Some time ago I was ranting about PHP and it’s “way” of handling FastCGI. The idea is to have persistent PHP-application which would handle requests from inside. This would allow us have “real” persistent cache in application (persistent connection to arbitary resources, preparsed XSLT’s in memory) and reply to queries really fast as we wouldn’t need to load all the classes on each request (classes would be loaded only once, during app initialization). And no, APC and similiar technologies do not completely solve this problem. [...] [...] Long story: Some time ago I was ranting about PHP and it’s “way” of handling FastCGI. The idea is to have persistent PHP-application which would handle requests from inside. This would allow us have “real” persistent cache in application (persistent connection to arbitary resources, preparsed XSLT’s in memory) and reply to queries really fast as we wouldn’t need to load all the classes on each request (classes would be loaded only once, during app initialization). And no, APC and similiar technologies do not completely solve this problem. [...]

]]> By: indeyets http://blog.milkfarmsoft.com/2006/06/fastcgi-in-php-the-way-it-could-be/comment-page-1/#comment-5925 indeyets Mon, 18 Jun 2007 18:12:47 +0000 http://blog.milkfarmsoft.com/?p=4#comment-5925 Stanislav: That's exactly what I am implementing right now. :) SCGI in pure php (FastCGI will be next) Stanislav: That’s exactly what I am implementing right now. :)
SCGI in pure php (FastCGI will be next)

]]> By: Stanislav Malyshev http://blog.milkfarmsoft.com/2006/06/fastcgi-in-php-the-way-it-could-be/comment-page-1/#comment-5924 Stanislav Malyshev Mon, 18 Jun 2007 18:08:30 +0000 http://blog.milkfarmsoft.com/?p=4#comment-5924 I see no reason why you can't implement FCGI protocol in long-running PHP script. However, PHP webserver model is targeted on (relatively) short isolated requests - that's how web applications work and that's how webservers expect them to work. It is not right that this is only for Apache's mod_php - it is true for *all* webserver SAPIs. There's nothing "improper" in PHPs FCGI implementation - FCGI is a protocol to communicate with the webserver and PHP implements it properly - it's just not meant to do what you want it to do, because it is oriented on different model of communication with the server and different model of applications. If, however, you do need the long-running script having its own event loop communicating with the web server, nothing prevents you from using non-webserver SAPI - namely CLI - and implementing the event loop inside your script on top of it. Well, not entirely correct - there's one thing: there's no PHP extension I know that implements it right now, so you'd have to either write one or parse all bits and bytes of FCGI in PHP (this BTW is exactly what Python is doing). If you find such module or implement it yourself, you are more than welcome to share it with the world :) However, while such things could be very useful, I don't see it becoming default model of running PHP over FCGI anytime soon. I see no reason why you can’t implement FCGI protocol in long-running PHP script. However, PHP webserver model is targeted on (relatively) short isolated requests – that’s how web applications work and that’s how webservers expect them to work. It is not right that this is only for Apache’s mod_php – it is true for *all* webserver SAPIs. There’s nothing “improper” in PHPs FCGI implementation – FCGI is a protocol to communicate with the webserver and PHP implements it properly – it’s just not meant to do what you want it to do, because it is oriented on different model of communication with the server and different model of applications.
If, however, you do need the long-running script having its own event loop communicating with the web server, nothing prevents you from using non-webserver SAPI – namely CLI – and implementing the event loop inside your script on top of it. Well, not entirely correct – there’s one thing: there’s no PHP extension I know that implements it right now, so you’d have to either write one or parse all bits and bytes of FCGI in PHP (this BTW is exactly what Python is doing). If you find such module or implement it yourself, you are more than welcome to share it with the world :) However, while such things could be very useful, I don’t see it becoming default model of running PHP over FCGI anytime soon.

]]> By: indeyets http://blog.milkfarmsoft.com/2006/06/fastcgi-in-php-the-way-it-could-be/comment-page-1/#comment-65 indeyets Tue, 10 Oct 2006 08:34:11 +0000 http://blog.milkfarmsoft.com/?p=4#comment-65 ajp is not as "beautiful" and complete solution as fastcgi, imho. ajp is not as “beautiful” and complete solution as fastcgi, imho.

]]> By: Henrik http://blog.milkfarmsoft.com/2006/06/fastcgi-in-php-the-way-it-could-be/comment-page-1/#comment-64 Henrik Mon, 09 Oct 2006 15:41:23 +0000 http://blog.milkfarmsoft.com/?p=4#comment-64 Just implement the AJP protocol and use the built in support in version 2.2 or mod_jk for previous versions. Just implement the AJP protocol and use the built in support in version 2.2 or mod_jk for previous versions.

]]>