Re: Mod_jk load balacing algorithm
Mohan2005 wrote: On the 'P' option which was recommended by Mladen Turk some time ago when we had issues (share memory locking) with a older version of mod_jk ( <1.2.15), we have left it as it is. There definitely were issues concerning optimistic locking around 1.2.15, but we expect them to be fixed in 1.2.18. But if you recommend that 'O' locking gives better performance on new mod_jk versions we will be looking into changing it after testing under our applications. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mod_jk load balacing algorithm
Hello: Thanks for those explainations. We will have to look further on the behavior of that server3_1 node. On the 'P' option which was recommended by Mladen Turk some time ago when we had issues (share memory locking) with a older version of mod_jk ( <1.2.15), we have left it as it is. But if you recommend that 'O' locking gives better performance on new mod_jk versions we will be looking into changing it after testing under our applications. Thanks -- View this message in context: http://www.nabble.com/Mod_jk-load-balacing-algorithm-tf2064844.html#a5701834 Sent from the Tomcat - User forum at Nabble.com. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mod_jk load balacing algorithm
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 139 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 3130WwwGroupServer2Com > 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 036 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 027 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 138 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 160 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 132 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 243 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 042 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 023 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 565 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 028 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mod_jk load balacing algorithm
Hello Thaks. We will enable loggin to find this, but since its a production setup will it affect performance ? 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 139 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 3130WwwGroupServer2Com 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 036 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 027 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 138 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 160 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 132 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 243 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 042 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 023 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 565 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 028 WwwGroupServer4Com 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 worker.loadbalancer.method=B worker.loadbalancer.local_worker_only=1 -- View this message in context: http://www.nabble.com/Mod_jk-load-balacing-algorithm-tf2064844.html#a5700083 Sent from the Tomcat - User forum at Nabble.com. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mod_jk load balacing algorithm
Hi, Mohan Wickramasinghe schrieb: > Hello > > We are using the "new" Busyness method with 1.2.18 > We have also using 'sticky sessions'. > > Clarification on > "> As soon as there will be real load, behaviour will differ." > > We have 9 nodes on 3 identitical servers with identical settings, lb > factor equal on all nodes, but we see one node which had got a large MAX > value (due to a large Busy number at some point), and one node that is not > getting hardly any requests. > > Why such deviations please with "Busyness" ? > Is it or could it be due to using 'sticky sessions' ? > Hard to tell without any numbers. Stickyness is somewhat contrary to load-balancing, but when the number of sessions grows, one would statistically expect the load to get even. You could increase JkLogLevel and add request logging to find out ore about the balancing decisions. Regards, 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]
Re: Mod_jk load balacing algorithm
Hello We are using the "new" Busyness method with 1.2.18 We have also using 'sticky sessions'. Clarification on "> As soon as there will be real load, behaviour will differ." We have 9 nodes on 3 identitical servers with identical settings, lb factor equal on all nodes, but we see one node which had got a large MAX value (due to a large Busy number at some point), and one node that is not getting hardly any requests. Why such deviations please with "Busyness" ? Is it or could it be due to using 'sticky sessions' ? > mod_jk neither supports round-robin, nor random load-balancing. > > Currently you can choose between three algorithms: > > method=B (busyness): choose the worker with the lowwest number of > requests currently in processing. > > method=R (requests): choose the worker that did the lowest number of > requests until now > > method=T (traffic): choose the worker that received+sent the lowwest > number of bytes until now > > In case you use "busyness", you might observe behaviour that's very > close to round-robin during times of very low load. If load is very low, > most of the time all workers will have no request in processing. So the > busyness counter will always be equal to zero. Then mod_jk will pick on > worker after the other, similar to round-robin. > > As soon as there will be real load, behaviour will differ. > > Regards, > > Rainer > > Sharma, Siddharth wrote: >> Is it possible to change mod_jk's load-balacing algorithm to random >> (from >> round robin)? >> If yes, how? >> >> TIA >> Sidd >> >> >> - >> To start a new topic, e-mail: users@tomcat.apache.org >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] > > - > 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]
RE: Mod_jk load balacing algorithm
Oh ok. I am not sure how I got the round-robin thing in my head. Anyhow, how does one configure this? I assume this is load balancer worker type configuration. -Original Message- From: Rainer Jung [mailto:[EMAIL PROTECTED] Sent: Monday, August 07, 2006 1:15 PM To: Tomcat Users List Subject: Re: Mod_jk load balacing algorithm mod_jk neither supports round-robin, nor random load-balancing. Currently you can choose between three algorithms: method=B (busyness): choose the worker with the lowwest number of requests currently in processing. method=R (requests): choose the worker that did the lowest number of requests until now method=T (traffic): choose the worker that received+sent the lowwest number of bytes until now In case you use "busyness", you might observe behaviour that's very close to round-robin during times of very low load. If load is very low, most of the time all workers will have no request in processing. So the busyness counter will always be equal to zero. Then mod_jk will pick on worker after the other, similar to round-robin. As soon as there will be real load, behaviour will differ. Regards, Rainer Sharma, Siddharth wrote: > Is it possible to change mod_jk's load-balacing algorithm to random (from > round robin)? > If yes, how? > > TIA > Sidd > > > - > To start a new topic, e-mail: users@tomcat.apache.org > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mod_jk load balacing algorithm
mod_jk neither supports round-robin, nor random load-balancing. Currently you can choose between three algorithms: method=B (busyness): choose the worker with the lowwest number of requests currently in processing. method=R (requests): choose the worker that did the lowest number of requests until now method=T (traffic): choose the worker that received+sent the lowwest number of bytes until now In case you use "busyness", you might observe behaviour that's very close to round-robin during times of very low load. If load is very low, most of the time all workers will have no request in processing. So the busyness counter will always be equal to zero. Then mod_jk will pick on worker after the other, similar to round-robin. As soon as there will be real load, behaviour will differ. Regards, Rainer Sharma, Siddharth wrote: Is it possible to change mod_jk's load-balacing algorithm to random (from round robin)? If yes, how? TIA Sidd - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
