tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kommuru, Bhaskar" <Bhaskar.Komm...@standardbank.co.za>
Subject RE: JK2: lb_factor
Date Tue, 22 Jun 2004 15:51:50 GMT
Hi Nicole & Micheal,

Thanks for your comments on this issue. lb_factor works fine although a bit
strange :D
The reason why my loadbalancing did not seem to work is I have tested with
small number of users. When I increased number of users and each user with
just one http call, I could see properly the way it load balances, which is
fine. 

Thanks for mentioning your "quotient calculations". that's helpful. 

I have notice one more thing. When you specify lb_factor & level same for
all of your clusters and test with small number of concurrent users, most of
the requests go to your local clusters. But if you increase number of
concurrent users to a large extent, then it load balances perfectly.

Cheers
Bhaskar

-----Original Message-----
From: Weseloh, Nicole [mailto:Nicole.Weseloh@lit.lineas.de]
Sent: Monday, June 21, 2004 4:52 PM
To: Tomcat Users List
Subject: RE: JK2: lb_factor


Hello Bhaskar (and everyone else who might be interested),

I've got good news: finally, loadbalancing with JK2 works great. :-) 
(And, best of it all: no recompiling of Apache was necessary! *g*)

The reason why loadbalancing did not work as it should: I used a test-tool
(in fact, Microsofts "Web Application Stress Tool") to generate a certain
amount of load (by simulating a certain number of clients & requests). The
tool has a pool of "users", each with an own session - however, I had more
sequences of requests than users, which means that some users (with existing
sessions) were re-used for the next requests. 

By default, stickySessions in jk2 are enabled, so if the requests belonged
to a formerly used session, they were - of course - not balanced as I
expected...

2 possibilities, each working perfectly well (depending on what you want to
do):
- increase number of users in the test tool (that's what worked for me -
maybe your problem is similar?)
- disable sticky sessions in your workers2.properties:
[lb:lb]
stickySession=JK_FALSE

Than every request - no matter if it belongs to an existing or a new session
- is balanced to another server, depending on the lb_factor. 

And yes, the lb_factor works fine, too, although a little bit strange ;-) :

lb_factor is the proportion of "all requests divided by number of request
for that instance".
e.g.:

You expect 10,000 requests totally, want them to be distributed to the
tomcat instances as follows:

Tomcat:	TC01		TC02		TC03
Requests:	2500		2500		5000
quotient:	4		4		2		(e.g.
10000/2500)
lb_factor:	2		2		1		(could also
be 4, 4 and 2, but should be as small as possible)


I tried something similar with mod_jk 1.2, which works as it is supposed to
do, too.

So - what have you set your "stickySessions" to, how do you generate your
requests, and where do you see which server handles them? Maybe we can
finally find out where your problem is, now we know that it *does* work...
;-)

Greets,
Nicole



	





-----Ursprüngliche Nachricht-----
Von: Michael Echerer [mailto:mech@tngtech.com] 
Gesendet: Freitag, 18. Juni 2004 22:25
An: Tomcat Users List
Betreff: Re: JK2: lb_factor



Kommuru, Bhaskar wrote:
> Thanks for you comments Michael,
> So mod_jk2.0.4 does not still seem to be a production quality 
> software. It doesnot work the way it is supposed to work as the 
> documentation. I have spent already a lot of time on this.
Actually the 10 Tomcat scenario I mentioned was with mod_jk1.x.y and Apache
2.0.46 (also prefork). I did it merely to verify a new mod_jk2 setup vs. an
existing one. Finally I found out that the old setup with
mod_jk1 didn't work either. ;-) Why did I start digging...
> I just want to confirm one thing here that it works and no matter what 
> your settings are :--(
By the way... The issue with remote and local workers, can be solved.
You have to set the level attribute for each channel in your
workers2.properties:

take for local workers:
level=0

for remote workers:
level=1

Usually you will set this for all your channels vice versa on e.g. two
Apache machines (each with e.g. 2 local Tomcats and 2 remote Tomcats).
In front of the 2 Apaches you could have a hardware lb.

The effect is that (each) Apache will only serve its local workers according
to its workers2.properties until (here: both!) all local Tomcats are
offline. So in this respect to mod_jk2 docu is quite okay. 
At least this part of the config works for me. I did't that any lb_factor
for the channels, only level to achieve this local/remote distribution.

If you don't like this you have to set the level equally for all your Tomcat
channels. Guess the local/remote levels are mainly to save some bandwith.

Michael
P.S. Until now I still think, that the best approach would be to try the
  MPM worker, instead prefork and check whether this has really a positve
effect. Any volunteers for compiling Apache 2.x "--with-mpm=worker" and
trying this?

> If you know any links which tells more details on this, Please let me
know.
> 
> Regards,
> Bhaskar
> 
> 
> -----Original Message-----
> From: Michael Echerer [mailto:mech@tngtech.com]
> Sent: Thursday, June 17, 2004 9:08 PM
> To: Tomcat Users List
> Subject: Re: JK2: lb_factor
> 
> 
> I measured similar effects using "The Grinder".
> Under maximum load with long running requests it can be even that 
> worse that one Apache 2.x (default compile: prefork) with 2 Tomcats
> 5.x/mod_jk2 only distributes to the first Tomcat at all.
> This is true as long as Apache runs out of MaxClients because of the 
> concurrent requests. Then, for some reason, Apache starts to 
> distribute also some load to the second Apache.
> So it might help if you lower MaxClients (this seems the only thing 
> that has an direct effect, not lb_factor, not ajp13 threads or 
> anything else) to force this earlier, but be aware that this might 
> produce errors if you get much more requests that then can't be queued
anymore.
> 
> I suppose Apache prefork and worker communication via shared memory by
> mod_jk2 don't work well together, or the don't work at all for true 
> round robin. Putting more than 2 Tomcats won't help with high load. I 
> once had 10 Tomcats, but in the end only the first few got most of the 
> load, Tomcat No 7-10 almost nothing.
> 
> I also heard that Apache MPM may help, but didn't try yet. So either I 
> forget something in my config, I have to use MPM (although nothing is 
> really mentioned about those issues in the docu), or mod_jk2 is really 
> not too good in this area.
> 
> Last advice: If you have that option to use a hardware router than I'd 
> suggest to use more Apaches with only one Tomcat behind each of them.
> This will definitely work best as those routers do a true round robin.
> 
> Ralph Einfeldt wrote:
> 
>>The quality of the distribution depends on the worker type of apache. 
>>(AFAIK only the 'worker' MPM will work)
>>
>>Nevertheless AFAIK the load balancing in mod_jk is not complete in 
>>this area, so I'm not shure if you will get the desired distribution 
>>(but it should be closer).
>>
>>
>>
>>>-----Original Message-----
>>>From: Weseloh, Nicole [mailto:Nicole.Weseloh@lit.lineas.de]
>>>Sent: Wednesday, June 16, 2004 11:48 AM
>>>To: tomcat-user@jakarta.apache.org
>>>Subject: JK2: lb_factor
>>>
>>>I've got a cluster with 2 tomcat 2.0.25 on different machines, on one 
>>>of them also running Apache 2.0.49 with JK2 as a loadbalancer. 
>>>Requests get redirected to both tomcat instances, but it always ends 
>>>up with around 1/3 of all requests at the local server and about 2/3 
>>>at the remote one, no matter what value the lb_factors are.
>>>
>>>So, could anyone tell me which values I should use to make the 
>>>lb_factor work correctly? All information I found was that "a lower 
>>>value means more requests" (official JK2-documentation at 
>>>jakarta.apache.org).
>>>
>>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>>
>>
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org




------------------------------------------------------------
Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
Informationen. Wenn Sie nicht der richtige Adressat sind oder diese
E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den
Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie
die unbefugte Weitergabe dieser Mail ist nicht gestattet.

This e-mail may contain confidential and/or privileged information. If
you are not the intended recipient (or have received this e-mail in
error) please notify the sender immediately and destroy this e-mail.
Any unauthorized copying, disclosure or distribution of the material
in this e-mail is strictly forbidden.


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
__________________________________________________________________________________________________________________________________

For information about the Standard Bank group visit our web site <www.standardbank.co.za>
__________________________________________________________________________________________________________________________________
	
Disclaimer and confidentiality note 
Everything in this e-mail and any attachments relating to the official business of Standard
Bank Group Limited  is proprietary to the group. 
It is confidential, legally privileged and protected by law. 
Standard Bank does not own and endorse any other content. Views and opinions are those of
the sender unless clearly stated as being that of the group. 
The person addressed in the e-mail is the sole authorised recipient. Please notify the sender
immediately if it has unintentionally reached you and do not read, 
disclose or use the content in any way.
Standard Bank can not assure that the integrity of this communication has been maintained
nor that it is free of errors, virus, interception or interference.
___________________________________________________________________________________________________________________________________

---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org


Mime
View raw message