Load-Balancing, High-Availability, and Sessions

Mike Brunt just posted the latest in a series of articles about high-availability web site architecture, with the conclusion that "the most effective Load Balancing in a Cluster is Round-Robin with Sticky-Sessions, if it is necessary to preserve state in a single user session."

The later portion of which would seem to be an interesting qualification.

After all, why would someone use memory-based sessions in an application meant to reside in a high-availability environment?

If your web site requires multiple servers (MSs) and load-balancing hardware (LBs), then restricting users to a single device would fall under the definition of "a bad thing".

First up is the obvious reason. If a server fails or is taken down for maintenance, then any user assigned to that server is hosed.

Second, if your traffic levels are that high, then it's possible your server could be maintaining thousands, if not millions of sessions over a given period before they timeout and are deleted. While RAM may be relatively cheap, there's a limit to the amount many servers can actually use.

Especially those based on earlier JVM's.

The solution? Manage session state via a database (client variables) or by using a dedicated application server cluster.

One reason often quoted for maintaining single-server connectivity are SSL-based transactions and the high overhead that can be needed to initiate a new session.

If that's an issue in your organization, then make sure you find the right hardware. Kemp, for example, will offload SSL encryption to the LB system using dedicated hardware.

This lets your servers do the job of processing transactions, and not let each one spin its wheels doing the extra work of encrypting content (often a 30-40% hit).

Offload SSL processing, and a three-server farm could easily do the work of five.

Always take a hard look at any "requirement" for session-based systems. Especially when scalability is an issue.

Comments

[Ken Sykora]

Good post - do you have any suggestions for those of us with large web apps that are already very deeply coupled with the session scope?

Also what kind of hardware exists for offloading SSL encryption? This is the first I have heard of such a thing.

[Mike Brunt]

Michael, thanks for this response to my posts, I appreciate it. I fully agree regarding database based client variables as a better alternative to memory resident Session variables. The challenge arises when complex objects are stored in the Session scope which cannot be stored in the Client scope. That is why I alluded to considerations about Clustering being built into any new web application at the architectural stage. The likely hood is that Clustering will occur; in my opinion.

[Mike Brunt]

Ken, most notable hardware Clustering devices support what is known as SSL Acceleration. This involves moving the handling of SSL Certificates off each individual web server to the Clustering device.

With regard to applications currently heavily vested in the use of the Session scope. If you have no complex objects in that scope Client variables are a worthy alternative. The other alternative is J2EE buddy Session Replication and with ColdFusion, this requires the Enterprise version.

[Nate Willard]

How can I learn more about Michael Long, the author?

[David Stockton]

In CF8 you can serialize a CFC to CLIENT scope; though obviously there can be a large amount of overhead involved here. You'd also need to be careful about keeping your .CFC code in sync with any data stored in CLIENT scope.

Someone also mentioned session sharing in a cluster. I've never found this to be very reliable with JRun. Has anyone else had experience of this in a production environment? How did you get on?

I think as is mentioned here, depending on your specific situation you need to come up with a plan to suit your needs - there's no "one size fits all" solution here.

[Michael Long]

David, While I agree there's no "one size fits all", there are best practices. And again, if your traffic levels are high enough that you need load-balancing, them you need to take a serious look at just what you're storing in the client and session scopes.

You mentioned serializing a CFC into a client, perhaps something like a login manager. Rather than go into that amount of overhead, why not create a login manager that can be created and cached in the application scope, but "manages" data stored in the client scope?