tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antonio Fiol Bonnín <>
Subject Session clustering and session stickiness - Performance issues (was Re: When is Tomcat 5 Release version scheduled to come out?)
Date Sun, 23 Nov 2003 07:50:42 GMT
Hello Remy,

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.

View raw message