Hello,
I'll begin from the end...
I did not present evidence, that is true, but I explained the symptoms. I tested three configurations:
1 Apache + 1 Tomcat; 1 Apache + 2 Tomcat; 1 Apache + 3 Tomcat
All three gave me very similar performance results. Measurement tool was "JMeter". Difficult pages were generated faster using three tomcats than using one tomcat, and trivial pages were faster with one tomcat.
Probably all this is due to the overhead of replicating the sessions, but I am not sure.
We also used Apache AB to test it. We did it against one nearly static JSP page. With low concurrency levels (less than 5), 2 tomcats give more throughput than one. With higher concurency levels (5 or more), 2 tomcats give worse throughput.
Probably, again, I think, because of the overhead of creating hundreds of sessions and replicating them. But, again, I am not sure.
You don't pretend to win the coveted Whiner Of The Month award with this, I hope. There's a lot of competition, you know.
A little more seriously:
- JMeter is IMO a bad load testing tool, but it's good at testing latencies.
- With your AB test, you are likely creating a session each time, which is basically the worst case for session clustering.
- You have to use session stickiness (the Servlet specification requires that operations related to a sigle session be bound to a single VM).
- JBoss session clustering is very likely a little more optimized (although it is not currently ported to Tomcat 5; coming soon).
You'll get better performance out of this form of clustering only if your webapp does a significant amount of computations. XML stuff is the prime example. If you are mostly DB based, you'll be moving the contention problems to the DB layer.
Given the throughtput a single Tomcat 5 with its HTTP connector gives on a decent server, I am surprised you are having problems unless you app is really processing intensive or your expected traffic is really high.
-- xxxxxxxxxxxxxxxxxxxxxxxxxxxxx R�my Maucherat Senior Developer & Consultant JBoss Group (Europe) S�RL xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
