FastCGI for Node
Christoph Dorn
It would be great if we could use Node as a webserver to service PHP, Perl, Python etc... requests, passthrough the response or process it further before returning to client.
It could be used to tie in FastCGI-enabled backend services into node apps.
I can also see uses for having Node support the FastCGI protocol as a runtime that can be plugged into any FastCGI server.
Christoph
Rasmus Andersson
Keep in mind most web servers with fcgi clients do NOT support
multiplexing (only one I know of implementing the complete FCGI 1.0
spec is zeus). I've written a async fcgi module for nginx which is
experimental which you can find here: http://github.com/rsms/afcgi
(also includes a reference implementation of an asynchronous fcgi
server, unrelated to nginx).
(I've written several FastCGI clients and servers, both sync and some
experimental async.)
>
> Christoph
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "nodejs" group.
> To post to this group, send email to nod...@googlegroups.com.
> To unsubscribe from this group, send email to
> nodejs+un...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en.
>
>
--
Rasmus Andersson
Ryan Dahl
connection alive between requests, even it only does one at a time?
This alone would almost be worth it. Handling requests out of order
would be really awesome though.
I'd like to support FastCGI. It's probably best as an external module
- although if someone put together a super cute and fast little parser
- I might include it in Node.
Rasmus Andersson
> Correct me if I'm wrong, Rasmus, but does NGINX keep the FastCGI
> connection alive between requests, even it only does one at a time?
Unfortunately not. It do keeps the internet client connection alive
though. So basically what happens is that for each request
(internally) nginx creates a new connection to the FastCGI server,
passes the request, waits and reads the response (forwarding it), and
then closes the FastCGI server connection. Nginx internals rely on the
closing of the fcgi server connection — it's messy, I know.
"problem: nginx needs fastcgi application to close connections after
it finished sending response. It uses connection close as flush
signal. Without this requests will hang." (Maxim Dounin on the nginx
list about the problem with fastcgi multiplexing support).
As I see it with node, you would probably create a single server which
is listening with N number of socket servers. Setup the fcgi client to
connect to any of those listening sockets. When a fcgi client connects
to one of the listening sockets, node internally keeps track of the
different requests in flight (if we expect only non-multiplexing
clients to connect, probably as simple as (X connection) == (Y
internet client) ).
> This alone would almost be worth it. Handling requests out of order
> would be really awesome though.
FastCGI was designed for multiplexing, but too bad there's only a few
complete client implementations.
>
> I'd like to support FastCGI. It's probably best as an external module
> - although if someone put together a super cute and fast little parser
> - I might include it in Node.
Honestly I don't really see fastcgi as a good alternative, or
replacement for HTTP proxying. HTTP upstreams can be persistent and
the only penalty, node-wise, is the overhead of HTTP parsing.
Is there a use-case where fastcgi (as we know it today --
non-multiplexing) in/with node would be feasible?
If there's a good use-case and an interest, I could probably port my
afcgi server[1] (C) or smisk dev server[2][3] (Python) to node.
[1] http://github.com/rsms/afcgi/tree/master/servers/afcgitest/
[2] http://github.com/rsms/smisk/blob/master/lib/smisk/util/fcgiproto.py
[3] http://github.com/rsms/smisk/blob/master/lib/smisk/util/httpd.py#L59
Christoph Dorn
I'd like to support FastCGI. It's probably best as an external module - although if someone put together a super cute and fast little parser - I might include it in Node.Honestly I don't really see fastcgi as a good alternative, or replacement for HTTP proxying. HTTP upstreams can be persistent and the only penalty, node-wise, is the overhead of HTTP parsing. Is there a use-case where fastcgi (as we know it today -- non-multiplexing) in/with node would be feasible? If there's a good use-case and an interest, I could probably port my afcgi server[1] (C) or smisk dev server[2][3] (Python) to node.
I was under the assumption that FastCGI would be more performant than HTTP proxying because the same PHP process is re-used for multiple requests. If that is not the case I can live with HTTP proxying. I am trying to gain access to PHP backend services from node to be able to leverage existing libraries and extensions until the node/js equivalents come along. Christoph
Rasmus Andersson
In that case you could run a FasCGI client in node and run a PHP
process in FastCGI server-mode. But I must say I find this idea of
using stuff in PHP very weird — PHP is an ugly hack that works
everywhere :P
>
> Christoph