creating scalable web application in rev using mod_load_balancer

[Andre Garzia]

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