Thank you sir, for helping us again. > 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 workers.properties 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? > > Rainer > > > --------------------------------------------------------------------- > To start a new topic, e-mail: users@tomcat.apache.org > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Regards Mohan Wickramasinghe --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
