[FASTCGI] Shouldn't Multiplexing be deprecated?
artyomtnk at yahoo.com
Mon Nov 15 02:23:41 EST 2010
Current FastCGI specification define Multiplexing of several connections
over the single socket.
There are actually two problems with this:
1. There is no way no make blocking notification to FastCGI
server in writing long response
2. No web server I aware of and almost no client library implement
Let's assume I have two clients requested for download two different 1GB files
FastCGI backend. Client #1 has 2.5 MB/s connection and other has slow 56KB/s
The first client would be able to download the file in about an hour while for
other it would
take about day and a half.
However fastcgi server is not aware of the connection speed and would likely to
responses in same speed. So the web server has two options:
a) either disconnect slow client
b) cache entire 1G response until the client completes download in 1.5 day.
Now if the web server has two distinct non-multiplexing connections it could
just not read the data from one of connections till the client consume its data
and allow the fastcgi server to block on the connection or put it into
select loop write-ability test.
Following web servers (I've checked) **do not** implement multiplexing:
1. Apache mod_fastcgi (official fastcgi package!)
2. Apache mod_fcgi (alternative fastcgi module)
5. IIS FastCGI module (from what I read, didn't check the code by myself as it
is not available)
Following client libraries (I've checked) **do not** implement
1. libfcgi - the official fastcgi libary
2. PHP - not implements
3. Then I stop checking...
So generally all popular production quality web servers that use FastCGI today
do not implement multiplexing.
Shouldn't multiplexing be deprecated?
More information about the FastCGI-developers