Help Desk
By Richard Yoo, guest Webmaster
Balancing Act
I'm part of a team that's writing a new intranet application using something similar to Microsoft Windows DNA. It uses HTML and JavaScript on the browser (no cookies), VB Web class on IIS (NT4), other stateless business/low level COM components on MTS (NT4), and stores its application states on Oracle. Each browser request looks up the user's state.
This should scale out in a Web farm because no state is stored on the IIS/MTS pair (I say pair because, due to DCOM limitations, each IIS box talks only to a single MTS box). We use a set of third-party components that require server affinity—they use the Global.ASA session object to store state, specifically a COM object reference. Secure HTTPS also requires server affinity, and this is what we're considering using. For scalability, how does request balancing (which we could support if we ignored our third-party component and HTTPS) compare with session balancing, which we're possibly stuck with?
—Mike
Where load balancing and fault tolerance are concerned, request balancing is by far the optimal solution. I'd be reluctant to use any COM object requiring session object affinity because of the severe load this could inflict upon a Web server, not to mention its scalability problems. Most ASP development guides warn against storing objects in session states due to session time-out issues and threading models. If requests are balanced across multiple servers, sessions will be distinct and state will be lost.
Fault tolerance is another factor.
