Kristian Rink schrieb:
> This seems reasonable. However, in terms of load balancing, I wonder
> whether there are any benchmark / comparisons on that:

Of course, stickyness and load balancing are contrary goals. So there
will be no solution with stikyness and perfect load balancing.

> - Using stickiness, I ensure each request of a session to run on the
> host the session initially was started upon. This way, the "session" is
> the most fine-grained way I can provide load balancing, but I possibly
> don't have to spend that much (development, runtime) resources in order
> to ensure session replication is always correct.
> 
> - Not using stickiness, and judging from my environment, I see that I
> can do load balancing on a per-request base, which seems to be a way
> more fine-grained approach especially in certain "imaginary worst-case"
> situations (given that the duration of sessions can drastically vary).
> But, however, this way indeed I do have to take at least runtime
> resources for session replication into consideration. 
> 
> Is there a meaningful approach to comparing these setups in terms of
> worst-case / average-case performance, or is it simply plain
> "trial-and-error" (and possibly some lambda-probe watching)?
> 

If you've got only two cluster nodes and need high availability, you
would need to size each of them to be able to handle 100% of your load.
So in this case good load balancing is not really important. It simply
gives you the chance to go over 100% and adjust hardware afterwards.

If you've got a lot of sessions and an app with relatively homogeneous
use cases, the sessions will statistically lead to equal load on the nodes.

If you've got few sessions, or very different session use cases, then in
fact you are in trouble :( concerning load balancing together with
stickyness.

You could experiment with the Busyness and the Sessions strategies for
the load balancer (atribute "method"), but they are not perfect either.

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]

Reply via email to