FastCGI

[Andre Garzia]

Hello Richard and Jim,

I've experimented with Revolution and fastcgi for while. I don't know
if you guys are familiar with FastCGI so I'll explain it first and
then tell the conclusions I came after trying it for a while.

>From wikipedia:
---------------------------

CGI is a protocol for interfacing external applications to web
servers. CGI applications run in a separate process, which is created
at the start of each request and torn down at the end. This "one new
process per request" model makes CGI programs very simple to
implement, but limits efficiency and scalability. At high loads, the
operating system process creation and destruction overhead becomes
significant and limits scalability. In addition, the CGI process model
limits resource reuse techniques (such as reusing database
connections, in-memory caching, etc.).

Instead of creating a new process for every request, FastCGI can use a
single persistent process which handles many requests over its
lifetime. Processing of multiple requests simultaneously is achieved
either by using a single connection with internal multiplexing (ie.
multiple requests over a single connection) and/or by using multiple
connections. Many such processes can exist, something that can
increase stability and scalability. FastCGI also allows programs to
get the web server to do certain simple operations, like reading in a
file, before the request is handed over. Environment information and
page requests are sent from the web server to the process over a TCP
connection (for remote processes) or Unix domain sockets (for local
processes). Responses are returned from the process to the web server
over the same connection. The connection may be closed at the end of a
response, but the web server and the process are left standing.

---------------------------

So in the end there are two components running, the web server and the
fastcgi process, and they communicate using TCP connections and a
binary protocol. Thru this connection they exchange all the control
stuff, the environment variables, the request and the response. As far
as binary standards goes, fastcgi is very straight forward and not
that hard to implement. FastCGI has internal multiplexing, that means
that the fastcgi process can receive mixed information about multiple
requests and should be able to deal with that but you can configure
apache not to do it and thus make your life easier, instead of
multiplexing the requests it will then queue them (IIRC).

This gives a couple advantages over plain old cgis. First, your
application is always running, it can compute on idle time, can keep
track of variables in memory, reuse db connections and the like.
There's no overhead on the exchange since all the initialization can
be done ahead of time when the process launches and leave it in a
pristine state for responding to requests.

So far you may be thinking, there's so much I could do with it, it
would simplify exchanging data between clients and everything but it's
not as simple as that. Revolution is a single thread engine and if
something bad happens, no matter if it is bad code or bad input, the
engine will block and might quit, this is bad enough in CGI but it
simply hangs for one given user, the one that started that specific
request, all the others are fine. With fastcgi, if the engine blocks,
all clients are blocked and if it doesn't quit, then you need to
manually go there and restart the process (unless you build your own
monitor app, but then, if the monitor app fails..)

Apache has a fastcgi monitor that is supposed to launch your fastcgi
process in the case it dies, but it doesn't work for revolution based
processes because the fastcgi process is supposed to launch, fork a
child and die, thus making the child a daemon process. We can't fork
in revolution so apache monitor fails do daemonize the process and
enters a loop...

In the end, for my own things, I decided against pursuing the fastcgi
solution. It was too dangerous, we have no way to salvage a blocked
engine. No try catch loop, no exception that can break away a infinite
loop or something. We can't fork internal processes in the fastcgi
server to deal with each request without the chance of blocking the
engine. Without thread or fork features, I will trust a fastcgi
solution. I might make some tool for me that uses fastcgi but I'd
never deploy or ship a product that can go so wrong as blocking the
whole userbase and never recovering.

One solution would be something like this:

Apache  <------> FastCGI Process <-------> individual request handlers
using some balancer application.

There are many load balancing servers out there. With them, you can
create a pool of server and the balancer will distribute the requests
among them. So you could create single request responders with
Revolution and use them, you could make the the fastcgi process keep
the db connection and variables and communicate thru tcp with the
balancer and the responders but this appears to be more complex than
just using cgis for me. I could never find a project that needed that
much complexity.

Cheers
andre



On Sat, Jan 24, 2009 at 10:41 PM, Jim Ault <JimAultWins at yahoo.com> wrote:
> I, too, am curious about this.
>
> One thing I would say is be very careful when using recursion.
>
> Jim Ault
> Las Vegas
>
>
> On 1/24/09 3:19 PM, "Richard Gaskin" <ambassador at fourthworld.com> wrote:
>
>> I just noticed my web hosting company offers FastCGI.  Any tips for
>> using that with Rev?
>>
>> --
>>   Richard Gaskin
>
>
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>



-- 
http://www.andregarzia.com All We Do Is Code.