Load balancing :

Load balancing is a computer networking methodology to distribute workload across multiple
computers or a computer cluster or other resources, to achieve optimal resource utilization,
maximize throughput, minimize response time, and avoid overload.

Some of the Features of a Load Balancer :

Asymmetric load: A ratio can be manually assigned to cause some backend servers to get a greater
share of the workload than others. This is sometimes used as a crude way to account for some
servers having more capacity than others and may not always work as desired.

Priority activation: When the number of available servers drops below a certain number, or load gets too
high, standby servers can be brought online

HTTP caching: the load balancer can store static content so that some requests can be handled without
 contacting the web servers.

Firewall: direct connections to backend servers are prevented, for network security reasons Firewall
 is a set of rules that decide whether the traffic may pass through an interface or not.

Content-aware switching: most load balancers can send requests to different servers based on the URL being requested.

The following two are important methods to balance a server load:

DNS round robin
Hardware load balancers.

Sticky session :

Sticky session refers to the feature of many commercial load balancing solutions for web
to route the requests for a particular session to the same physical machine that serviced
the first request for that session. This is mainly used to ensure that the in-progress session
is not lost as a result of requests for a session being routed to different servers.

Since requests for a user are always routed to the same machine that first served the request
for that session, sticky sessions can cause uneven load distribution across servers. If the
first accessed server is down for any reason User may lose the Session Data no Session
Replication happens in Sticky Session.

Here is the Sample load balancer Set up with apache MOD_PROXY

   ProxyPass / balancer://mycluster/ stickysession=JSESSIONID nofailover=On
        ProxyPassReverse / ajp://yourcompany.com:8009
        ProxyPassReverse / ajp://yourcompany.com:8009
        <Proxy balancer://mycluster>
          BalancerMember ajp://yourcompany.com:8009 loadfactor=20
          BalancerMember ajp://yourcompany.com:8009 loadfactor=5
          ProxySet lbmethod=byrequests
        </Proxy>

Cluster :

 A cluster is a group of servers running a Web application simultaneously, appearing to the world
as if it were a single server. To balance server load, the system distributes requests to
different nodes within the server cluster, with the goal of optimizing system performance.
This results in higher availability and scalability -- necessities in an enterprise,
Web-based application.

High availability - if a single Web server fails, then another server takes over, as transparently
as possible, to process the request.

Scalability - Scalability is an application's ability to support a growing number of users.

Consideration for making your application Clusterable:

When you want to make your application Clusterable, you have to first identify what are thing
(which holds the State data)should be synchronized among all the Machines in the Cluster for
supporting High avialblity Without impacting the application functionality.
Here are the list of things you should look at.

HTTP Session (Session Replication) :
     In a Clustered ENV, your application server keep the HttpSession state in Sync among all
  the Servers in Cluster, this could be by using different communication technique
  like IP MultiCast etc. So for better performance you have to do the following.

        i) Try to keep little data in HttpSession, do not keep pretty big Object graphs in
  HttpSession, becase each change to Session Data would triggers  session replication
  which serializes the Session state and transport that to all the Servers in cluster.

     ii) All the Objects stored in Session should be Seriazable , if not Session
   replication would be failed.

Stateful session beans :
   You should take the same considetaions as above, even in StateFul Session Beans case.

Singleton classes :
     By design as Singleton classes would be maintained as One Instance per JVM, so making
  a Singleton class Custable is a little Chanllenging as all the JVMs in any given Clusttered
  ENV would have their own Instance of Singleton classes.  So you have to manually keep
  the  One possible solution for this issue is below.

i)  Serialize the First Instance of a singleton class and store in Database. Serialize the
    First Instance of a singleton class which is created on any JVM and store that in Database,
 let all other JVMs check in Database if a singleton class was already created before
 Creating their own Instance, this way we can make sure that the same Instance is being used
 by all the Servers.

JMS Queues:
You may need to use Distributed Queues or Topics.

Back to top