I'd also like to see a sticky test as most of the clusters I have
worked with use a high-end hardware load balancer (although I do find
this test very interesting). I'd also like to see the test use a
larger and mutating session. One of the things that will effect
latency is the time (and effort) it takes to move the session data.
With people sticking large caches of detached JPA objects in sessions
now days, I'd like to know how that effects my application performance.
Finally, how about a wadi vs tribes on Tomcat?
BTW you should talk to Jason about testing this on GBuild, so you can
test in a true distributed state.
-dain
On Oct 18, 2007, at 12:02 AM, ikarzali wrote:
jgenender wrote:
Excerpt of the conclusion:
"
The effectiveness of the design and implementation of WADI's
distributed
session lookup engine and replication engine is further comforted
by the
observed average response times and scalability characteristics.
For the considered scenarios, WADI performs better than Terracotta,
which is not really surprising as...
If I may comment here...Without fine-grained clustering
capabilities, I
have a hard time believing that WADI can outperform Terracotta.
Especially with large objects...WADI would push over the entire
object
each time, where Terracotta would only ship the changed members.
If you
are going to publish the numbers you did, you probably should explain
what is getting pushed across.
Interesting test of Terracotta. I wouldn't trust any test that
pegs the CPU
at 100%. May I suggest the following potential changes:
1. Running Jetty, Grinder, and Terracotta on a single laptop should
change.
Run Terracotta on its own server. It will run faster even though
it won't
be over loopback.
2. Run sticky and see what happens. See, the test is not testing
the same
thing with WADI and Terracotta. With WADI, the clustering
implementation is
configured to keep data on a finite number of nodes. With
Terracotta, you
have a consistent clustered view of sessions. Since you are round-
robin,
with Terracotta every node is holding a reference to every session
and as
the sessions change, all Jetty nodes are updated with the change.
So, round
robin WITH WADI replication off is actually pretty much cheating
because TC
has the sessions in all nodes and WADI has them in one. Run sticky
sessions
in your load balancer. Then Terracotta will have the session in
one node
just like WADI. _Then_ you will have apples-to-apples and maybe
find TC
latency to be lower and throughput higher.
I would be happy to help explain more but this use of WADI and
Terracotta
seem like you are getting opposite behaviors out of the products
(full n-way
replication with no SPoF under Terracotta versus zero replication
under
WADI) and a different test will more accurately reflect the relative
performance of the systems.
--Ari
--
View this message in context: http://www.nabble.com/Effectiveness-
of-WADI%27s-Design-and-Implementation-Comforted-
tf4640401s134.html#a13269164
Sent from the Apache Geronimo - Dev mailing list archive at
Nabble.com.
