jesus at omniti
Jul 24, 2002, 12:36 PM
Post #1 of 1
Theo Schlossnagle wrote:
Re: [mod_backhand-devel] Basic question about load balancing and mod_backhand
> Roy Barman, Shashwata wrote:
>> I have a basic question about mod_backhand and load balancing.
>> First take the simple situation. There is only one web server A and the
>> application root URL is
>> http://A.ffci.com/logon.jsp . The web application is a series of HTTP
>> request and response between the browser and
>> the webserver. We simulate the concept of state[ HTTP is inherently
>> stateless] using HTTPsession in the webserver.
>> Every thing is working fine.
>> Now we decide to create a server farm or web cluster by adding
>> webservers B,
>> C . Here load balancing comes into
>> play. The user should type in the browser the same
>> http://A.ffci.com/logon.jsp but depending on the load it should get
>> translated to one of [ http://A.ffci.com/logon.jsp or
>> http://B.ffci.com/logon.jsp or
>> http://C.ffci.com/logon.jsp ]. The problem [ which I am not clear] is
>> here. After first time the user gets
>> connected to a server all further requests should go to same server
>> till he
>> closes the browser. How can I achieve this ?
>> To summarize we want load balancing [ automatic re-routing] to work
>> only for
>> the URL http://A.ffci.com/logon.jsp
>> [ the application root].
>> Can we do this ?
>> Also if the server A has shutdown/crashed how can we transparently route
>> requests to B or C ?
> So, the fact that you store session state locally on once server is a
> fundamental scalability issue. You can't load balance requests
> anymore, only sessions. Apparently the world isn't prepared to make
> that leap (or paradigm shift) to store session state in a distributed
> cache. Sigh.
> So, sticking a session to a server? Backhand can do this easily.
> Your application does need to tag the user via a Cookie or some other
> mechanism -- otherwise there is no way for mod_backhand to realize.
> Take a look at the bySession function (and the README for it in the
> source distribution -- also on the web site).
> Also, take a look at the archives of this list. This has been
> discussed before.
I take that back... not much is discussed on the devel list... This has
been discussed on the users list and you will probably find _those_
OmniTI Computer Consulting, Inc. -- http://www.omniti.com/
Phone: +1 301 776 6376 Fax: +1 410 880 4879
1024D/82844984/95FD 30F1 489E 4613 F22E 491A 7E88 364C 8284 4984
2047R/33131B65/71 F7 95 64 49 76 5D BA 3D 90 B9 9F BE 27 24 E7