UnixServerAdmin

Server Administration & Management

worker.properties_cluster

##############################################################
# workers to contact, that’s what you have in your httpd.conf
worker.list=loadbalancer

# setup tomcat1
worker.tomcat1.port=8109
worker.tomcat1.host=localhost
worker.tomcat1.type=ajp13
worker.tomcat1.lbfactor=1

# setup tomcat2
worker.tomcat2.port=8209
worker.tomcat2.host=localhost
worker.tomcat2.type=ajp13
worker.tomcat2.lbfactor=1

# setup tomcat3
worker.tomcat3.port=8309
worker.tomcat3.host=localhost
worker.tomcat3.type=ajp13
worker.tomcat3.lbfactor=1

# setup the load-balancer
worker.loadbalancer.type=lb
worker.loadbalancer.method=R/S/T/B
worker.loadbalancer.balance_workers=tomcat1,tomcat2,tomcat3
worker.loadbalancer.sticky_session=True
#worker.loadbalancer.sticky_session_force=True

# Status worker for managing load balancer
worker.status.type=status
##################################################################

worker.list –> Describe the workers that are available to Apache via a list

ajp13 –> This type of worker represents a running Tomcat instance

lb –> used for load balancing

status –> display useful information about how the load among the various Tomcat workers is distributed

Sticky sessions are an important feature if you rely on jSessionIDs and are not using any session-replication layer. If sticky_session is True a request always gets routed back to the node which assigned this jSessionID.
If that host should get disconnected, crash or become unreachable otherwise the request will be forwarded to another host in the cluster.

R :- Request –> If method is set to Request the balancer will use number of requests to find the best worker. Accesses will be distributed according to the lbfactor in a sliding time window. This is the default value and should be working well for most applications.

S :- Session –> If method is set to Session the balancer will use number of sessions to find the best worker. Accesses will be distributed according to the lbfactor in a sliding time window. Because the balancer does not keep any state, it actually does not know the number of sessions. Instead it counts each request without a session cookie or URL encoding as a new session. This method will neither know, when a session is being invalidated, nor will it correct its load numbers according to session timeouts or worker failover. This method should be used, if sessions are your limiting resource, e.g. when you only have limited memory and your sessions need a lot of memory.

T :- Traffic –> If set to Traffic the balancer will use the network traffic between JK and Tomcat to find the best worker. Accesses will be distributed according to the lbfactor in a sliding time window. This method should be used, if network to and from the backends is your limiting resource.

B :- Busyness –> If set to Busyness the balancer will pick the worker with the lowest current load, based on how many requests the worker is currently serving. This number is divided by the workers lbfactor, and the lowest value (least busy) worker is picked. This method is especially interesting, if your request take a long time to process, like for a download application.
##############################################################

Advertisements

March 19, 2012 - Posted by | Apache, Cluster, Tomcat | , ,

No comments yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: