tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <rainer.j...@kippdata.de>
Subject Re: Mod_jk load balacing algorithm
Date Tue, 08 Aug 2006 07:03:30 GMT
Hi,

Mohan2005 schrieb:
> Hello
> 
> Thaks. We will enable loggin to find this, but since its a production setup
> will it affect performance ?

The numbers suggest, that you've got

210.000 * 12(instances) / 21 (days) = 120.000 requests/day
So depending on the time distribution, this should boild down to about 5
requests/second peak load. If your local disks are modern and there is
enough file system space for the log, enabling debug log level should be
OK. But: rethinking my suggestion, I think the needed info will *not* be
in the logs.

> 
> This is a set of stats. Apache was running for 3 weeks. (Hope this is clear)
> mod_jk 1.2.18 with Busyness and sticky sessions (all nodes are identicical).
> 
> 
> Name       Type  jvmRoute  Host               Addr               Stat D F M
> V Acc     Err Wr   Rd   Busy Max RR Cd
> server1_1  ajp13 server1_1 172.16.1.138:8009  172.16.1.138:8009  OK   0 1 1
> 1 181792  22  152M 16G  1    39     WwwGroupServer1Com
> server2_1  ajp13 server2_1 172.16.1.139:8009  172.16.1.139:8009  OK   0 1 1
> 3 218096  37  185M 18G  3    130    WwwGroupServer2Com
> server3_1  ajp13 server3_1 172.16.1.135:8009  172.16.1.135:8009  OK   0 1 1
> 1 32348   1   29M  2.8G 0    36     WwwGroupServer3Com
> server4_1  ajp13 server4_1 172.16.1.140:8009  172.16.1.140:8009  OK   0 1 1
> 1 192940  23  164M 16G  0    27     WwwGroupServer4Com
> server2_2  ajp13 server2_2 172.16.1.139:18009 172.16.1.139:18009 OK   0 1 1
> 1 209807  33  178M 17G  1    38     WwwGroupServer2Com
> server3_2  ajp13 server3_2 172.16.1.135:18009 172.16.1.135:18009 OK   0 1 1
> 1 208006  67  174M 18G  1    60     WwwGroupServer3Com
> server1_2  ajp13 server1_2 172.16.1.138:18009 172.16.1.138:18009 OK   0 1 1
> 1 148020  17  126M 13G  1    32     WwwGroupServer1Com
> server4_2  ajp13 server4_2 172.16.1.140:18009 172.16.1.140:18009 OK   0 1 1
> 2 203780  16  174M 17G  2    43     WwwGroupServer4Com
> server1_3  ajp13 server1_3 172.16.1.138:38009 172.16.1.138:38009 OK   0 1 1
> 0 178381  11  148M 15G  0    42     WwwGroupServer1Com
> server2_3  ajp13 server2_3 172.16.1.139:38009 172.16.1.139:38009 OK   0 1 1
> 0 196352  11  162M 16G  0    23     WwwGroupServer2Com
> server3_3  ajp13 server3_3 172.16.1.135:38009 172.16.1.135:38009 OK   0 1 1
> 5 184697  10  154M 16G  5    65     WwwGroupServer3Com
> server4_3  ajp13 server4_3 172.16.1.140:38009 172.16.1.140:38009 OK   0 1 1
> 0 175744  34  145M 14G  0    28     WwwGroupServer4Com

There are obviously two workers, with uneven numbers: server3_1 and to
some minor degree server1_2. Number 3_1 really looks suspicious. Maybe
it has been in error status/down/stopped/disabled for a longer time?

Remember: method "B" tries to keep "Busy" even. This could mean, that
the workers get different numbers of requests over a longer time.
Nevertheless I would not expect such huge differences as with 3_1. All
other numbers are plausible for "B" with stickyness.

The differences in Busy numbers (0 to 5) could be related to stickyness.
If you are using URL encoding you can have a look into the apache access
logs to determine the rate of requests going to tomcat, that carry
session info. If you are using Cookies, you can log the incoming
"Cookie" header in the log (check docs for mod_log_config for the syntax
for incoming headers) and do the same check.

If you've got relatively few requests without session, then think of it
as first feeding most requests into their sticky slot and then adding
only a few to the remaining slots with lowest (usually 0 or 1) busyness.

> In workers.properties...
> worker.loadbalancer.balance_workers=server1_1, server2_1, server3_1,
> server4_1, server2_2, server3_2, server1_2, server4_2, server1_3, server2_3,
> server3_3, server4_3
> 
> worker.loadbalancer.lock=P

Did you have any reason for "P"? Recent versions seem to run OK with
"O", which should perform better.

> worker.loadbalancer.method=B
> worker.loadbalancer.local_worker_only=1

The last one (local_worker_only) doesn't exist any more (and wouldn't
have made sense in this situation). It gets ignored.

Regards,

Rainer

---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message