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 <[email protected]> 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" <[email protected]> wrote: > >> I just noticed my web hosting company offers FastCGI. Any tips for >> using that with Rev? >> >> -- >> Richard Gaskin > > > _______________________________________________ > use-revolution mailing list > [email protected] > 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. _______________________________________________ use-revolution mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
