Something we should also check is the CPU load of the Tomcat instance.
May be it will be usefull also to let users/admin add their own
counters in the load estimation.
For example, if some admins considers we should base the
load-balancing on HTTP requests or SQL access, and they have these
Henri Gomez wrote:
Something we should also check is the CPU load of the Tomcat instance.
May be it will be usefull also to let users/admin add their own
counters in the load estimation.
If you want to add this to Tomcat remeber that stuff needs a JNI module
to collect information from the
Well many beans are allready available :
java.lang.Theading
java.lang.MemoryPool
I could see also some beans related to CPU load but using a Sun JVM
(not on IBM).
2007/7/5, jean-frederic clere [EMAIL PROTECTED]:
Henri Gomez wrote:
Something we should also check is the CPU load of the Tomcat
Hi Rainer,
seems we have still an issue in jvm config. we have not noticed the
concurrent mode gc failures that led to tomcat overload and bad responses.
14896.148: [Full GC 14896.148: [CMS (concurrent mode failure):
1102956K-326641K(2359296K), 4.0684463 secs] 1280549K-326641K(3067136K),
[CMS
Hi Rainer,
seems we have still an issue in jvm config. we have not noticed the
concurrent mode gc failures that led to tomcat overload and bad responses.
14896.148: [Full GC 14896.148: [CMS (concurrent mode failure):
1102956K-326641K(2359296K), 4.0684463 secs] 1280549K-326641K(3067136K),
[CMS
Yefym Dmukh wrote:
Actually the following was happening: the LB sends requests and gets the
session sticky, continuously sending the upcoming requests to the same
cluster node. At the certain period of time the JVM started the major
garbage collection (full gc) and spent, mentioned above, 20
Yefym Dmukh wrote:
Actually the following was happening: the LB sends requests and gets the
session sticky, continuously sending the upcoming requests to the same
cluster node. At the certain period of time the JVM started the major
garbage collection (full gc) and spent, mentioned above, 20
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
it simple approach ?
Mladen Turk [EMAIL PROTECTED]
05.07.2007 13:19
Please respond to
Tomcat Developers List dev@tomcat.apache.org
To
Tomcat Developers List dev@tomcat.apache.org
cc
Subject
Re: Feature request /Discussion: JK loadbalancer improvements for high
load
Yefym Dmukh wrote
Mladen wrote:
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)
The main
OK, this culd make sense, i.e. heap nearly full on node1 failover to
other cluster member node2 (replcation assumed) and trigger GC by
System.gc() on node1. Interesting idea ... (for JK3 and beyond).
Yefym Dmukh wrote:
Mladen wrote:
This won't help much. The sticky session requests must be
Question, why would you need GC,heap or CPU stats from the Tomcat
machine at all?
in most cases, none of these stats can predict response times.
The best way would be to simply record a history of response times, and
then mod_jk can have algorithms (maybe even pluggable) on how to use
those
Question, why would you need GC,heap or CPU stats from the Tomcat
machine at all?
in most cases, none of these stats can predict response times.
The best way would be to simply record a history of response times, and
then mod_jk can have algorithms (maybe even pluggable) on how to use
those
Hi all,
sorry for the stress but it seems that it is a time to come back to the
discussion related to the load balancing for JVM (Tomcat).
Prehistory:
Recently we made benchmark and smoke tests of our product at the sun high
tech centre in Langen (Germany).
As the webserver apache2.2.4 has
14 matches
Mail list logo
