Multiplexing FastCGI module

[Maxim Dounin]

Hello!

On Sun, Dec 13, 2009 at 06:31:06PM +0100, Rasmus Andersson wrote:

> Hi.
> 
> I've written a multiplexing (concurrent requests through a single
> backend) version of the 0.8 fastcgi module along with a FastCGI server
> reference implementation:
> 
> http://github.com/rsms/afcgi
> 
> Please let me know what you think and if you're interested in merging
> in this code upstream.

[Just a side note: there are lots of whitespace damage and style 
violations in your code.  It's belived that following original 
nginx style is good idea, makes reading diffs easier and improves 
karma.]

I wasn't able to find enough code there to keep backend 
connections alive and share them between requests.  Looks like the 
code in question just assigns unique ids to requests sent to 
fastcgi backend - while each request is still send in separate 
connection...

On the other hand, it sets FASTCGI_KEEP_CONN flag and thus breaks 
things as nginx relay on fastcgi application to close connection.

So basically it's not something usefull right now.  And it breaks 
3 out of 4 fastcgi subtests in the test suite 
(http://mdounin.ru/hg/nginx-tests/).

As to idea in general - I'm not really sure that request 
multiplexing is great feature of fastcgi protocol.  It complicates 
things and shouldn't be noticably faster than just using multiple 
connections to the same fastcgi app (assuming fastcgi app is able 
to handle connections asynchroniously).  It would be intresting to 
compare though.

Maxim Dounin

p.s. As keeping fastcgi connections alive appears to be 
prerequisite for fastcgi multiplexing, here are some notes:

Keeping fastcgi connections alive isn't really hard, but requires 
a lot more than setting KEEP_CONN flag in fastcgi request.  Most 
notably - ngx_event_pipe code and upstream module code should be 
modified to make sure buffering is somewhat limited and does not 
relay on connection close as end signal.  I've posted some preview 
patches a while ago which makes fastcgi module able to keep 
connections alive (with ngx_http_upstream_keepalive module), you 
may want to take a look if you are going to continue your 
multiplexing work.