I did not pretend to be whining. Sorry if it souded like that.
And thank you very much for your response: I find it really useful.
First, thank you for confirming my worries about JMeter not being the best available load testing tool.
** [OT] Do you know of a better (free if possible) load testing tool, which supports cookies and HTTPS? AB doesn't, AFAIK.
When you say "you have to" use session stickiness:
** Do you mean as an alternative, or combined with session clustering. I can't see clearly the point of combining them.
You also say: "only if your webapp does a significant amount of computations". Our webapp does a significant amount of XSLT work on a few pages, but most of them consist only on personalized versions of a static page (the user name is printed on the top, that's all). That is what I meant by "difficult" and "trivial". So I guess our app is not the type of app that will benefit from session clustering.
And about our worries: we are expecting something similar to slashdot effect, i.e. the webapp itself is a moderate traffic one which can be easily served with a single Tomcat. However, our marketing people expect a very high traffic (x100 or so) for a few hours and a high traffic (x10 or so) for a few days. They expect a (x2 - x5) permanaent increase. For the permanent increase, I am not worried. It is the "x100" that worries me seriously.
Other than that, our "production" architecture consists of: 2 load balancers + 2 Apache + 2 Tomcat + 1 Database
** Do the load balancers need to know about session stickiness or is it just the mod_jk on the Apache that needs it?
Thank you very much.
Antonio Fiol
Remy Maucherat wrote:
Antonio Fiol Bonnín wrote:
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.
smime.p7s
Description: S/MIME Cryptographic Signature
