Hello, on 04/09/2008 03:07 PM steve said the following: >>> FastCGI is *the* way to run PHP, but I think Apache is not the >>> platform for it anymore. >> If need more than one server, Apache pre-forked model may limited. >> Otherwise it is just fine. Other than that, I think there are some >> features that only work with Apache SAPI. > > Apache SAPI is the easiest. But it falls apart when you have a higher > load. FastCGI can stall those who are thinking of getting their second > webserver. When you have a whole farm of them the differences are > grossly obvious. Sure, but it also adds overhead when replying to HTTP requests. There are no miracles. >>> Is the COMMET implementation on the client side long polling >>> (reconnect) or does it stream using script tags? What goes on in the >>> server? Does it push the buffer of blank data that WebKit requires? Is >>> it a PHP daemon process running as a simple HTTP server? >> Actually it is just an hidden iframe that loads an HTML page with small >> Javascript chunks that flush each COMET AJAX server response. This is a >> regular HTTP request performed to the same script that serves that form. >> The form AJAX plug-in can detect the AJAX request and respond >> adequately. So it works equally well in all browsers including Webkit. > > So you keep a whole Apache/PHP process open for each user? That is > nice for a small site, but doesn't work with tens of thousands of > simultaneous connections. :( No, I did not say that. "AJAX" requests using this approach are triggered on demand. For PHP is like any other request. Executing an AJAx request this way or a regular request submiting a form or following a link consumes just one process. > Webkit has a bug/feature that it would buffer the incoming data until > it reached 1024 bytes. You can see how the django server deals with it > in their comet implementation: > http://code.google.com/p/django-evserver/source/browse/trunk/comet.py > > Orbited also uses 100 "<span></span>" as padding. Maybe you are talking about some other Comet approach. Last time I tried the approach that I described with Safari, I did not see any delay due to buffering. But if there is any delay imposed by any browsers, it would not be hard to add any padding. > So does meteor I believe. Here is what they say: > "Safari and IE have a buffer which must fill up before any response is > parsed. Data received before the buffer is full will not be rendered > or interpreted and will not fire the Interactive state of an XHR until > the buffer is full or the connection is closed. The obvious solution The approche described above does not render anything nor uses XMLHTTPRequests. It is just a regular page with some Javascript loaded in an hidden iframe. That Javascript communicates and updates with the iframe parent page. -- Regards, Manuel Lemos PHP professionals looking for PHP jobs http://www.phpclasses.org/professionals/ PHP Classes - Free ready to use OOP components written in PHP http://www.phpclasses.org/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
