Re: [PHP] APC & FastCGI != upload progress ?
- From: iamstever@xxxxxxxxx (steve)
- Date: Wed, 9 Apr 2008 11:07:51 -0700
On Sat, Apr 5, 2008 at 7:44 PM, Manuel Lemos <mlemos@xxxxxxx> wrote:
on 04/04/2008 03:16 AM 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.
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. :(
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.
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
to this is to send a blob of 'noise' at the start of any response that
needs to be parsed incrementally. The size of the buffer that needs to
be filled is 512 bytes in Internet Explorer, and between 256 bytes and
1K in Safari depending on the Content-type of the response (a
non-standard content-type equals a 256b buffer, while a text/html
content type may be as much as 1K) " from
http://meteorserver.org/browser-techniques/xssinfo
It is also mentioned a bit in http://en.wikipedia.org/wiki/Comet_(programming)
-s
.
- Follow-Ups:
- Re: [PHP] APC & FastCGI != upload progress ?
- From: Manuel Lemos
- Re: [PHP] APC & FastCGI != upload progress ?
- References:
- Re: [PHP] APC & FastCGI != upload progress ?
- From: Manuel Lemos
- Re: [PHP] APC & FastCGI != upload progress ?
- From: steve
- Re: [PHP] APC & FastCGI != upload progress ?
- From: Manuel Lemos
- Re: [PHP] APC & FastCGI != upload progress ?
- Prev by Date: Re: [PHP] dynamic boxes problem... JS and PHP
- Next by Date: Re: [PHP] Requested PHP apps / sites
- Previous by thread: Re: [PHP] APC & FastCGI != upload progress ?
- Next by thread: Re: [PHP] APC & FastCGI != upload progress ?
- Index(es):
Relevant Pages
|