You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Rainer Jung <ra...@kippdata.de> on 2007/08/30 17:50:55 UTC

Re: max number of supported lb workers

Concerning mod_jk there is no hard upper limit. If the number of workers
(counting all lb workers and all members of lb workers comes close to
64, you will need to increase the JkShmSize.) No dependency on the 
tomcat or AJP version. I didn't think about old JK versions though. 
1.2.23 doesn't count as old.

Concerning performance: Load balancers with long lists of member workers
will become slightly slower, because they have to search the correct
worker in the list (and some similar things). Usually this added latency
should still be very small relatively to handling requests generating
dynamic content on the backend. As always: if you go to extremes, you
might get some unexpected experience. I would expect 15 members to be no
problem at all.

You can easily test this for the non sticky case: configure 15 members
to an lb and let them point to the same tomcat. Run some tests and retry
with all but one of the members removed. I would expect the difference
in performance to be lower, than the correctness of the observation.

Be sure to configure enough Tomcat threads when doing this test, because
each of the 15 workers will have its own connection pool (although they
all point to the same host and port).

If your farms grows up, you might want to consider partition apsects. 
You can run those systems homogeneously, but for bigger numbers one 
often starts to think about using the redundancy to improve 
availability. So often you end up with different network cells and a 
related design concerning the httpd instances (although a much smaller 
number). You can then express preferences in the mapping from httpd to 
Tomcat with the workers distance parameter. Such a preference does not 
influence stickyness, i.e. session affinity (if activated, which is the 
default) always comes first. but in case the request doesn't carry a 
session (or you don't use session stickyness), the distance attribute 
gives you a way of configuring prefered Tomcat instances.

Regards,

Rainer

Javor Evstatiev wrote:
> Hi list,
> 
> We use 3 loadbalanced tomcat workers (tomcat 4.1.18 (!) ), fronted by
> apache2, mod_jk 1.2.23.
> 
> They are defined as follows:
> 
> ... worker.worker1.type=ajp13 worker.worker2.type=ajp13 
> worker.worker2.type=ajp13 ... 
> worker.loadbalancer.balanced_workers=worker1, worker2, worker3 ...
> 
> We are experiencing very high load and bad application response
> times, so we are going for more workers.
> 
> What is the maximum supported number of lb workers? Does it depend on
> the ajp version, or on the tomcat version? How many of you are
> running an installation with 15 or maybe more workers?
> 
> best,
> 
> JE

---------------------------------------------------------------------
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