Phi-Long LE wrote:
Ian,
reading optional directives you should probably use the
worker.xxx.method, its value is Request, session, traffic or busyness
Default is request. For most use cases this should work best.
How does it work?
1) Multiple Web server instances do not share any information about
load. So they decide completely independently.
2) request method: mod_jk counts the requests going to each worker and
whenever a request has no session associated it chooses the worker with
the smallest number. The first request after every 60 seconds will
trigger a maintenance cycle, which divides all counters by 2, such that
historic data gets less important. If you use load factors, the counters
get adjusted by the load factors. Bigger load factors will result in
bigger load (and smaller increments to the counters).
3) If a worker comes back after error, it will start with the biggest of
the actual counters, to prevent it from getting a request storm.
4) busyness method: this looks at the number of request which are
actually in the middle of processing. Could be OK for download sites,
but usually does not work that well. Especially bad, if your side is not
high traffic.
5) traffic: the same as request method, but counts bytes transferred
instead of requests done. The bytes are only added after the requests
have finished, so if you have long running downloads, the byte counters
will ot change for a long time and then change a lot.
Having multiple instances work independently should be no problem, if
statistics count: this means: you have a lot of traffic, and the
percentage of requests without sessions is not too small. In other
words: you have a lot of users and the sessions are not taking to long.
Load balancing might run into asymmetries, if you have very long lasting
in house sessions and very different types of users. Then some heavily
used sessions might produce the most load.
On the other hand: as long as you only operate two backends, the quality
of the load balancing might not be very important, because out of
availybility considerations usually one of the two nodes should be able
to handle the maximum load. :)
Regards,
Rainer
Le 21/06/2007 16:00, Ian Buzer a écrit :
Thanks for that Rainer.
How about when a new session comes in? Does mod_jk obtain information
from
each Tomcat about its current load, or does it base it on the number of
requests that that particular instance of mod_jk has forwarded to
Tomcat? If
it's the latter, is this likely to cause problems?
Thanks
Ian
-----Original Message-----
From: Rainer Jung [mailto:[EMAIL PROTECTED]
Sent: 21 June 2007 15:50
To: Tomcat Users List
Subject: Re: Two IIS web servers
Yes, this will work. The only bad thing will be, that the requests
belonging to one session will be logged partially on both of the IIS
instances, so if you try to debug a problem, you always need to look at
both IIS servers.
Stickyness works like this:
- you set a unique jvmRoute in the engine element of server.xml
- Tomcat appends the jvmRoute to each sessionid it generated, with a
dot
as a separator
- mod_jk load balancer looks for a session id whenever it receives a
request and strips of the routing string behind the dot
- if mod_jk finds such a routing strings, the load balancer searches
for
a worker with the same name or with a route attribute with the same
value and sends it there
So mod_jk does not hold any state information about where which session
lies. Every request carries the information with it.
Regards,
Rainer
Ian Buzer wrote:
Hi,
I currently have one IIS server balancing requests to two Tomcats
using JK
1.2. I am using JK to provide sticky sessions and all is working
well.
I would like to be able share requests across a second IIS server,
however I
am unable to create sticky sessions at the web server level so
requests
could go to either web server.
My question is, if I point both IIS servers to both Tomcats, will
this work
correctly? Will the sessions still get directed to the correct
Tomcat, and
will the two JKs still be able to choose the best worker for new
sessions?
Many thanks
Ian
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
