Hello Friends, this topic begins the week of web app related articles and posts by yours truly. Encouraged by the previous topics in the previous emails about web application, I'll quickly talk about one of the caveats of building web application server with revolution and propose a solution.
Most of our web applications are CGI based. The problems of a CGI approach are: * For all requests a new copy of the engine is launched, the stacks and code loaded. Meaning there's a little (very little) overhead when dealing with each connection. * Your CGI is like a newborn when it starts, it has no clue what is happening, it needs to consult it's sessions and databases to discover where in the workflow it is. Meaning that the stateless nature of the web and cgis do not help when building an application with a complex workflow. * database connections are open and closed with every connection (this is more an elegance problem than an actual problem). * Your application is not running when there's no request so you can execute code during those idle moments. Your apps is only alive when someone is accessing it, when the request is done, the engine is down, you can however use the dead time between answering the browser and shutting down the engine to execute maintenance tasks but this is a hack and not really the best way to deal with the fact that you may need your application code to be always running. During RevConWest I've demoed FastCGI that solved all this problems, specially the last one. I've demoed a simple application that would increment an integer so when you accessed the software you could see the value going up even when you were not using the application. If you can't think of any application that needs to be running at all times just wonder how a stock market web application should behave, how can your client learn about the flunking of SCO paper if the app is not running when it happens? The problem with FastCGI is that it uses a single engine for all connection, so if for some weird reason your code blocks, all the requests block too and your application is on Denial of Service till this is solved. In the end my FastCGI implementation, although cool, was never released to public use due to the pain it would be to support all the blocked services. Now a solution. Yes, I do have a solution that actually solves everything. With Apache web server version 2.0 and up, a new module was released. It is called mod_proxy_balancer. A combination of this module and multiple instances of RevHTTP can do miracles. Apache mod_proxy_balancer will act as a proxy directing chosen connections to it's team members which are called proxyBalancers. One can launch, for example, five instances of RevHTTP and tell apache that those are the five proxybalancers. Then for each request, apache will choose the RevHTTP instance that is available and direct the connection there, if some instance is busy or blocked apache will detect that and direct to some other instance. This creates an average load on all RevHTTP instances and allows your code to be running at all time. You can fine tune that so that apache serves all the static files (html, images) and that your balancer team is just used for the cgi calls thus making the load on them even lower. This technique is being used by the guys from the ruby on rails camp with success. It's used for real world work. Apache will take care of scheduling all the requests, it will also deal with blocked processes and the like. I plan to make a tutorial and example on this shortly. Andre _______________________________________________ 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
