tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mladen Turk <mt...@apache.org>
Subject Re: Feature request /Discussion: JK loadbalancer improvements for high load
Date Thu, 05 Jul 2007 11:56:46 GMT
Yefym Dmukh wrote:
>> You have oxymoron here. With session stickiness you are willingly
>> tear down the load balancer correctness because you don't wish/can
>> have session replication.
> 
> Generally you are right, but the ideal world is not the reality:
> we use apache my faces implementation of jsf where the core session class 
> size is about 500KB, the compression of state kills CPU, the size kills 
> session replication/failover approach. So we have is what we have aqnd we 
> are trying to get the best out of it. 
>

For 10 nodes the replication cost would be to high even for a smaller
session class, but you can at least use domain clustering model,
and slice that to 5x2 nodes.

> BTW, what about the bidirectional jvm-lb connection and the stop-the-world 
> GC managed by lb, as keep it simple approach ? 
> 

This won't help much. The sticky session requests must be served
by the same node (group of nodes if using domain clustering),
and your requests will still be delayed by the JVM instance GC cycle
(It has to happen sometime, and you cannot depend on request
void intervals)

Of course since LB updates it's statistics after the request, and if
the request is delayed, right now we cannot react proactive on queued
requests, so new request can be delayed as well instead passed to the
node that is not within the GC cycle (during the GC cycle itself).

To solve the later problem we don't need the two-way communication,
because this can be solved by the LB by taking into account the number
of queued request as well, but we need it for a different things.

However all this is major technology upgrade and it's part of JK3 roadmap,
because it requires both protocol and substantial code change.


Regards,
Mladen.

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


Mime
View raw message