Shouldn't Multiplexing be deprecated?
Artyom <artyomtnk-/[email protected]> Sun, 14 Nov 2010 23:23:41 -0800 (PST)
| Newsgroups | gmane.comp.web.fastcgi.devel |
|---|---|
| Message-ID | <[email protected]> |
Hello All, 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 multiplexing 1st problem: ------------ Let's assume I have two clients requested for download two different 1GB files from FastCGI backend. Client #1 has 2.5 MB/s connection and other has slow 56KB/s connecton 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 push both 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. 2nd problem: ------------ Following web servers (I've checked) **do not** implement multiplexing: 1. Apache mod_fastcgi (official fastcgi package!) 2. Apache mod_fcgi (alternative fastcgi module) 2. Lighttpd 3. Nginx 4. Cherooke 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 multiplexing. 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? ===================================== Artyom