[FASTCGI] Shouldn't Multiplexing be deprecated?

Preston L. Bannister preston at bannister.us
Mon Nov 15 10:59:15 EST 2010


What would be gained by deprecating multiplexing? I do not see a gain.

Since we are talking about implementations that do not exist, it is a bit
hard to debate relative merits.

Note that your (potential) problem of slow/large traffic exists for
non-multiplexed connections, if the size of the pool of FastCGI connections
has an upper limit.

If you can create new connections, and you can detect when all existing
connections are busy, then create a new connection. Note that this approach
applies (potentially) to both multiplexed connections as well as
non-multiplexed.

Note also that in practice, the probability of the problem scenario is
somewhat less. Very large transfers are best broken into smaller pieces,
especially when going over slower/less reliable links.


If someone wants to push a C10K problem using FastCGI, then having a
specification for multiplexed FastCGI is at least somewhat useful, though it
seems they would have to create their own server-side implementation.


On Sun, Nov 14, 2010 at 11:23 PM, Artyom <artyomtnk at yahoo.com> wrote:

> 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
>
>
>
>
> _______________________________________________
> FastCGI-developers mailing list
> FastCGI-developers at mailman.fastcgi.com
> http://mailman.pins.net/mailman/listinfo.cgi/fastcgi-developers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.pins.net/mailman/private.cgi/fastcgi-developers/attachments/20101115/e1c2d98f/attachment.html>


More information about the FastCGI-developers mailing list