Hello!
On Sat, Mar 09, 2013 at 10:43:47PM +0800, Ji Zhang wrote:
> Hi,
>
> I'm doing some research on FastCGI recently. As I see from the FastCGI
> specification, it does support multiplexing through a single
> connection. But apparently none of the current web servers, like
> Nginx, Apache, or Lighttpd supports this feature.
>
> I found a thread from nginx dev mailing list back to 2009, stating
> that multiplexing won't make much difference in performance:
> http://forum.nginx.org/read.php?29,30275,30312
>
> But I also find an interesting article on how great this feature is,
> back to 2002:
> http://www.nongnu.org/fastcgi/#multiplexing
This article seems to confuse FastCGI multiplexing with
event-based programming. Handling multiple requests in a single
process is great - and nginx does so. But you don't need FastCGI
multiplexing to do it.
> I don't have the ability to perform a test on this, but another
> protocol, SPDY, that recently becomes very popular, and its Nginx
> patch is already usable, also features multiplexing. So I'm curious
> about why spdy's multiplexing is great while fastcgi's is not.
>
> One reason I can think of is that tcp connection on the internet is
> expensive, affecting by RTT, CWND, and other tube warming-up issue.
> But tcp conneciton within IDC (or unix-domain socket on localhost) is
> much cheaper. Besides, the application can also go the event-based
> way, to accept as much connections as it can from the listening socket
> and perform asynchronously.
>
> Does my point make sense? or some other more substantial reasons?
You are correct, since FastCGI is used mostly for local
communication, multiplexing on application level isn't expected to
be beneficial. Another reason is that multiplexing isn't
supported (and probably will never be) by the major FastCGI
application - PHP.
There were several discussions on FastCGI multiplexing here, and
general consensus seems to be that FastCGI multiplexing might
be useful to reduce costs of multiple long-polling connections to
an application, as it will reduce number of sockets OS will have
to maintain. It's yet to be demonstrated though.
--
Maxim Dounin
http://nginx.org/en/donation.html
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx