# Why Nginx Doesn't Implement FastCGI Multiplexing? **URL:** \ **Category:** NGINX\ **Created:** [March 9, 2013, 3:44pm UTC](https://www.ruby-forum.com/t/why-nginx-doesnt-implement-fastcgi-multiplexing/227266 "2013-03-09T15:44:12Z")\ **Posts on this page:** 17\ **Page:** 2
**Author:** ![Ji\_Zhang](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/0ea827/32.png) [@Ji\_Zhang](https://www.ruby-forum.com/u/Ji_Zhang)\ **Post date:** [July 20, 2013, 7:05am UTC](https://www.ruby-forum.com/t/why-nginx-doesnt-implement-fastcgi-multiplexing/227266/21 "2013-07-20T07:05:58Z")
What proxy module does in that case? You said earlier HTTP lacks flow conrol too. So what is the difference? Posted at Nginx Forum: > **[Re: Why Nginx Doesn't Implement FastCGI Multiplexing?](https://forum.nginx.org/read.php?2,237158,241059#msg-241059)** > > 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.... ---
**Author:** ![Ji\_Zhang](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/0ea827/32.png) [@Ji\_Zhang](https://www.ruby-forum.com/u/Ji_Zhang)\ **Post date:** [July 20, 2013, 7:10am UTC](https://www.ruby-forum.com/t/why-nginx-doesnt-implement-fastcgi-multiplexing/227266/22 "2013-07-20T07:10:03Z")
On Jul 20, 2013, at 9:05 , momyc wrote: > What proxy module does in that case? You said earlier HTTP lacks flow conrol > too. So what is the difference? The proxy module stops reading from backend, but it does not close backend connection. It reads again from backend when some buffers will send to the slow client. – Igor S. > **[F5 NGINX: Built for cloud-native apps. Ready for AI traffic.](https://www.f5.com/products/nginx)** > > Deliver modern applications with NGINX. Explore high-performance load balancing, API gateways, and web server solutions trusted by top global enterprises. ---
**Author:** ![Ji\_Zhang](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/0ea827/32.png) [@Ji\_Zhang](https://www.ruby-forum.com/u/Ji_Zhang)\ **Post date:** [July 20, 2013, 7:01am UTC](https://www.ruby-forum.com/t/why-nginx-doesnt-implement-fastcgi-multiplexing/227266/23 "2013-07-20T07:01:17Z")
On Jul 20, 2013, at 8:41 , momyc wrote: > OK, it probably closes connection to backend server. Well, in case of > multiplexed FastCGI Nginx should do two things: > > 1. send FCGI\_ABORT\_REQUEST to backend for given request > 2. start dropping records for given request if it still receives records > from backend for given request Suppose a slow client. Since nginx receives data quickly backend will send data quickly too because it does not know about slow client. At some point buffered data surpasses limit and nginx has to abort connection to backend. It does not happen if backend knows a real speed of the client. – Igor S. > **[F5 NGINX: Built for cloud-native apps. Ready for AI traffic.](https://www.f5.com/products/nginx)** > > Deliver modern applications with NGINX. Explore high-performance load balancing, API gateways, and web server solutions trusted by top global enterprises. ---
**Author:** ![Ji\_Zhang](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/0ea827/32.png) [@Ji\_Zhang](https://www.ruby-forum.com/u/Ji_Zhang)\ **Post date:** [July 20, 2013, 7:24am UTC](https://www.ruby-forum.com/t/why-nginx-doesnt-implement-fastcgi-multiplexing/227266/24 "2013-07-20T07:24:05Z")
What do you mean by “stop readning”? Oh, you just stop checking if anything is ready for reading. I see. Well, this is rude flow control I’d say. Proxied server could unexpectedly drop connection because it would think Nginx is dead. There is a nice feature I don’t remember how exactly it’s called when some content could be buffered on Nginx (in proxy mode) and there is strict limit of how much could be buffered and when it goes to file. This is what could be used for that case. If buffer overflow happens close client, abort backend, drop records for that request. Keep connection and keep receiving and de-multiplexing records for good requests. Posted at Nginx Forum: > **[Re: Why Nginx Doesn't Implement FastCGI Multiplexing?](https://forum.nginx.org/read.php?2,237158,241062#msg-241062)** > > 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.... ---
**Author:** ![Ji\_Zhang](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/0ea827/32.png) [@Ji\_Zhang](https://www.ruby-forum.com/u/Ji_Zhang)\ **Post date:** [July 20, 2013, 7:25am UTC](https://www.ruby-forum.com/t/why-nginx-doesnt-implement-fastcgi-multiplexing/227266/25 "2013-07-20T07:25:50Z")
“abort backend” meant “abort request” Posted at Nginx Forum: > **[Re: Why Nginx Doesn't Implement FastCGI Multiplexing?](https://forum.nginx.org/read.php?2,237158,241063#msg-241063)** > > 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.... ---
**Author:** ![Ji\_Zhang](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/0ea827/32.png) [@Ji\_Zhang](https://www.ruby-forum.com/u/Ji_Zhang)\ **Post date:** [July 20, 2013, 7:43am UTC](https://www.ruby-forum.com/t/why-nginx-doesnt-implement-fastcgi-multiplexing/227266/26 "2013-07-20T07:43:22Z")
On Jul 20, 2013, at 9:23 , momyc wrote: > What do you mean by “stop readning”? Oh, you just stop checking if anything > is ready for reading. I see. Well, this is rude flow control I’d say. > Proxied server could unexpectedly drop connection because it would think > Nginx is dead. TCP will say to backend that nginx is alive. It can drop only after some timeout. > There is a nice feature I don’t remember how exactly it’s called when some > content could be buffered on Nginx (in proxy mode) and there is strict limit > of how much could be buffered and when it goes to file. This is what could > be used for that case. If buffer overflow happens close client, abort > backend, drop records for that request. Keep connection and keep receiving > and de-multiplexing records for good requests. Yes, but it is useless to buffer a long polling connection in a file. – Igor S. > **[F5 NGINX: Built for cloud-native apps. Ready for AI traffic.](https://www.f5.com/products/nginx)** > > Deliver modern applications with NGINX. Explore high-performance load balancing, API gateways, and web server solutions trusted by top global enterprises. ---
**Author:** ![Ji\_Zhang](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/0ea827/32.png) [@Ji\_Zhang](https://www.ruby-forum.com/u/Ji_Zhang)\ **Post date:** [July 20, 2013, 7:11am UTC](https://www.ruby-forum.com/t/why-nginx-doesnt-implement-fastcgi-multiplexing/227266/27 "2013-07-20T07:11:49Z")
If it’s time to close backend connection in non-multiplexed configuration just send FCGI\_ABORT\_REQUEST for that particular request, and start dropping records for that request received from the backend. Please shoot me any other questions about problems with implementing that feature. Posted at Nginx Forum: > **[Re: Why Nginx Doesn't Implement FastCGI Multiplexing?](https://forum.nginx.org/read.php?2,237158,241061#msg-241061)** > > 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.... ---
**Author:** ![Ji\_Zhang](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/0ea827/32.png) [@Ji\_Zhang](https://www.ruby-forum.com/u/Ji_Zhang)\ **Post date:** [July 20, 2013, 9:53am UTC](https://www.ruby-forum.com/t/why-nginx-doesnt-implement-fastcgi-multiplexing/227266/28 "2013-07-20T09:53:37Z")
> it is useless to buffer a long polling connection in a file. For Nginx there is no any difference between long-polling or other request. It would’t even know. All it should care is how much to buffer and for how long to keep those buffers until droping them and aborting request. I do not see any technical problem here. Posted at Nginx Forum: [http://forum.nginx.org/read.php?2,237158,241066#msg-241066](http://forum.nginx.org/read.php?2,237158,241066#msg-241066) ---
**Author:** ![Ji\_Zhang](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/0ea827/32.png) [@Ji\_Zhang](https://www.ruby-forum.com/u/Ji_Zhang)\ **Post date:** [July 20, 2013, 10:18am UTC](https://www.ruby-forum.com/t/why-nginx-doesnt-implement-fastcgi-multiplexing/227266/29 "2013-07-20T10:18:09Z")
> Yes, but it is useless to buffer a long polling connection in a file. Buffering of some data on Web-server is fine as long as client receives whatever server has sent or client gets closed connection. If sending is not possible after buffers are full dropping client connection and aborting request is not a problem. Problems like that should be dealt with on higher level of abstraction. Posted at Nginx Forum: [http://forum.nginx.org/read.php?2,237158,241068#msg-241068](http://forum.nginx.org/read.php?2,237158,241068#msg-241068) ---
**Author:** ![Ji\_Zhang](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/0ea827/32.png) [@Ji\_Zhang](https://www.ruby-forum.com/u/Ji_Zhang)\ **Post date:** [July 20, 2013, 11:18am UTC](https://www.ruby-forum.com/t/why-nginx-doesnt-implement-fastcgi-multiplexing/227266/30 "2013-07-20T11:18:55Z")
On Jul 20, 2013, at 11:52 , momyc wrote: > > it is useless to buffer a long polling connection in a file. > > For Nginx there is no any difference between long-polling or other request. > It would’t even know. All it should care is how much to buffer and for how > long to keep those buffers until droping them and aborting request. I do not > see any technical problem here. There is no technical problem. There is an issue of practical utility of such backend. There are two types of backend: 1. The first one uses a large amount of memory to process request. It should send a generated response as soon as possible and then moves to a next request. nginx can buffer thousands of such responses and sends them to clients. Persistent connection between nginx and backend and nginx buffering help in this case. Multiplexing just complicates the backend logic without any benefit. The bottle neck here is not number of connections to a single listen port (64K) but amount of memory. 2. The second type of backend uses a small amount of memory per request, can process simultaneously thousands of clients and does NOT need buffering at all. Multiplexing helps such backends but only together with a flow control. – Igor S. > **[F5 NGINX: Built for cloud-native apps. Ready for AI traffic.](https://www.f5.com/products/nginx)** > > Deliver modern applications with NGINX. Explore high-performance load balancing, API gateways, and web server solutions trusted by top global enterprises. ---
**Author:** ![Ji\_Zhang](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/0ea827/32.png) [@Ji\_Zhang](https://www.ruby-forum.com/u/Ji_Zhang)\ **Post date:** [October 4, 2013, 3:44pm UTC](https://www.ruby-forum.com/t/why-nginx-doesnt-implement-fastcgi-multiplexing/227266/31 "2013-10-04T15:44:10Z")
I would also like to add a vote for FCGI multiplexing. There is no obligation for backends, since non-implementing backends can indicate FCGI\_CANT\_MPX\_CONN in response to a FCGI\_GET\_VALUES request by nginx. The other poster has already mentioned FCGI\_ABORT\_REQUEST and dropping response packets from dangling requests. My scenario is that I have a variety of requests: some take a while, but others are a quick URL rewrite culminating in a X-Accel-Redirect. This rewrite involves complicated logic which is part of my overall backend application., which I would rather not factor out and rewrite into a nginx module The actual computation for the URL rewrite is miniscule compared to the overhead of opening/closing a TCP connection, so FCGI request multiplexing would be of great help here. If the overhead of a multiplexed FCGI request starts to approach doing the work directly in an nginx module, it would give a valuable alternative to writing modules. This would avoid the pitfalls of writing modules (code refactoring, rewriting in C, jeopardizing nginx worker process, etc.). Posted at Nginx Forum: > **[Re: Why Nginx Doesn't Implement FastCGI Multiplexing?](https://forum.nginx.org/read.php?2,237158,243430#msg-243430)** > > 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.... ---
**Author:** ![Ji\_Zhang](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/0ea827/32.png) [@Ji\_Zhang](https://www.ruby-forum.com/u/Ji_Zhang)\ **Post date:** [October 4, 2013, 6:49pm UTC](https://www.ruby-forum.com/t/why-nginx-doesnt-implement-fastcgi-multiplexing/227266/32 "2013-10-04T18:49:27Z")
Hello! On Fri, Oct 04, 2013 at 09:43:41AM -0400, DevNginx wrote: > application., which I would rather not factor out and rewrite into a nginx > module The actual computation for the URL rewrite is miniscule compared to > the overhead of opening/closing a TCP connection, so FCGI request > multiplexing would be of great help here. > > If the overhead of a multiplexed FCGI request starts to approach doing the > work directly in an nginx module, it would give a valuable alternative to > writing modules. This would avoid the pitfalls of writing modules (code > refactoring, rewriting in C, jeopardizing nginx worker process, etc.). Your use case seems to be perfectly covered by a keepalive connections support, which is already here. See [Module ngx\_http\_upstream\_module](http://nginx.org/r/keepalive). – Maxim D. > **[nginx: donation](http://nginx.org/en/donation.html)** ---
**Author:** ![Ji\_Zhang](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/0ea827/32.png) [@Ji\_Zhang](https://www.ruby-forum.com/u/Ji_Zhang)\ **Post date:** [October 5, 2013, 5:12pm UTC](https://www.ruby-forum.com/t/why-nginx-doesnt-implement-fastcgi-multiplexing/227266/33 "2013-10-05T17:12:54Z")
## Maxim D. Wrote: > Your use case seems to be perfectly covered by a keepalive connections > > support, which is already here. See [Module ngx\_http\_upstream\_module](http://nginx.org/r/keepalive). OK, yeah that would work for me. Thanks. There is still the possibility that long running requests could clog the connections, but I can work around that by listening on two different ports and having nginx route the quickies to their dedicated port. Posted at Nginx Forum: [http://forum.nginx.org/read.php?2,237158,243454#msg-243454](http://forum.nginx.org/read.php?2,237158,243454#msg-243454) ---
**Author:** ![Ji\_Zhang](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/0ea827/32.png) [@Ji\_Zhang](https://www.ruby-forum.com/u/Ji_Zhang)\ **Post date:** [September 14, 2014, 9:22pm UTC](https://www.ruby-forum.com/t/why-nginx-doesnt-implement-fastcgi-multiplexing/227266/34 "2014-09-14T21:22:48Z")
Question about FastCGI: How it handle simultaneous connections with one process when PHP itself is blocking language ? What if I have something “sleep(100)” . Wont it block the process for the other users ? Thanks Maxim D. wrote in post #1101079: > Hello! > > On Sat, Mar 09, 2013 at 10:43:47PM +0800, Ji Zhang wrote: > > > But I also find an interesting article on how great this feature is, > > back to 2002: > > [FastCGI — The Forgotten Treasure](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. > > > 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 D. > [nginx: donation](http://nginx.org/en/donation.html) ---
**Author:** ![Ji\_Zhang](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/0ea827/32.png) [@Ji\_Zhang](https://www.ruby-forum.com/u/Ji_Zhang)\ **Post date:** [September 15, 2014, 12:44pm UTC](https://www.ruby-forum.com/t/why-nginx-doesnt-implement-fastcgi-multiplexing/227266/35 "2014-09-15T12:44:27Z")
Hello! On Sun, Sep 14, 2014 at 09:22:48PM +0200, Wter S. wrote: > Question about FastCGI: How it handle simultaneous connections with one > process when PHP itself is blocking language ? What if I have something > “sleep(100)” . Wont it block the process for the other users ? > Thanks FastCGI doesn’t imply PHP (and, actually, PHP doesn’t imply blocking as well - there are some event-driven PHP frameworks out there). As of now, implementation of the FastCGI protocol in PHP doesn’t support FastCGI multiplexing at all, and that’s one of the reasons why nginx doesn’t implement FastCGI multiplexing as well. Quoting the message you’ve replied to: > > … Another reason is that multiplexing isn’t > > supported (and probably will never be) by the major FastCGI > > application - PHP. – Maxim D. > **[nginx](http://nginx.org/)** ---
**Author:** ![Ji\_Zhang](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/0ea827/32.png) [@Ji\_Zhang](https://www.ruby-forum.com/u/Ji_Zhang)\ **Post date:** [September 16, 2014, 2:01pm UTC](https://www.ruby-forum.com/t/why-nginx-doesnt-implement-fastcgi-multiplexing/227266/36 "2014-09-16T14:01:15Z")
Hello! On Mon, Sep 15, 2014 at 06:16:58PM +0200, Wter S. wrote: > Then how Nginx is able to handle thousands simultaneous requests (where > some of them contains blocking IO operations) with only one process (or > let say 10 processes) ? That’s because nginx is event-driven server and uses non-blocking IO whenever possible. – Maxim D. > **[nginx](http://nginx.org/)** ---
**Author:** ![Ji\_Zhang](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/0ea827/32.png) [@Ji\_Zhang](https://www.ruby-forum.com/u/Ji_Zhang)\ **Post date:** [September 15, 2014, 6:16pm UTC](https://www.ruby-forum.com/t/why-nginx-doesnt-implement-fastcgi-multiplexing/227266/37 "2014-09-15T18:16:58Z")
Maxim D. wrote in post #1157635: > Hello! > > On Sun, Sep 14, 2014 at 09:22:48PM +0200, Wter S. wrote: > > ## FastCGI doesn’t imply PHP As of now, implementation of the FastCGI protocol in PHP doesn’t support FastCGI multiplexing at all, and that’s one of the reasons why nginx doesn’t implement FastCGI multiplexing as well. > > Maxim D. > [http://nginx.org/](http://nginx.org/) Then how Nginx is able to handle thousands simultaneous requests (where some of them contains blocking IO operations) with only one process (or let say 10 processes) ? Thanks ! [Previous page](https://www.ruby-forum.com/t/why-nginx-doesnt-implement-fastcgi-multiplexing/227266.md?page=1)