tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <>
Subject Re: "Busy" in jkmanager
Date Wed, 05 Jul 2006 15:34:31 GMT
Mohan2005 wrote:
> Specifies what method load balancer is using for electing best worker. If
> method is set to R[equest] balancer will use number of requests to find the
> best worker. If set to T[raffic] balancer will use the network traffic
> between JK and Tomcat to find the best worker. If set to B[usyness] 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.
> And from your previous post you said..
> and I quote..
> "Busy=number of parallel requests being processed for a worker at that point
> of time."
> and where "request = HTTP Request in progress"
> Please clarify the difference between the 'Request' method and the 'Busy'
> method you had defined.

All statements are true, but maybe confusing: For method "B" we only 
take into account the requests, that are being processed at the moment 
the next balancing decision has to be made (i.e. the next request comes 
in). So "B" will lead to nearly the same number of requests in work for 
every worker whenever you do a snapshot observation.

For method "R" we accumulate, how many requests a worker has processed 
in the past. So "R" will lead to the same number of requests being 
accumulated by each worker, e.g. when you count that from your log files.

Since the pure "R" strategy has negative side effects, we divide the 
number of requests done once a minute by 2, so that the past counts less 
the longer it is away.

> This is very important for us, since we currently use the 'Request' method
> in and we want to know the exact working of the 2 methods
> (Busy and Request). Since we plan on switching to a method that is best
> suited for performance and proper load balancing.

Depending on the kind of workload B or r (or even T) could be better. B 
does the better Job on balancing parallelity, R does better balance 
accumulated work.

Last minor point: B looks simpler and better understandable, but there 
is a small synchronization overhead with B, bevause B needs to change 
status counters 2 times per request (before and after), R only needs to 
add before and divide once in a minute.

> Our main confusion here is that both the 'Request' and 'Busy' methods refer
> to the same criteria, which is "Number of Requests'

I hope this sounds clearer now?


To start a new topic, e-mail:
To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message