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.
Jeff,
from Gianny's article:
"In order to efficiently cluster the few online solutions having a
rather big session size, WADI offers an alternative replication
mechanism, which only replicates field updates or method executions
against replicas."
So, WADI offers a delta-based replication route as well - but this was
not the one under test.
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.
Ari,
I know nothing about Terracotta, so would you mind spending a little
more time comparing and contrasting architectures...
I agree that the best case scenario is fully functional stickiness - but
then you would simply be testing session replication - see Gianny's
"Session Replication Test" explanation and results.
Every now and then, stickiness is not enough - for instance when you
take down or lose a node (unless Terracotta has some form of integrated
load-balancer which negotiates a session's new location). WADI is
designed to work with the LCD - a loadbalancer which will just dump the
subsequent request for a dead node anywhere in the cluster and then restick.
Thus the worst case scenario, often an interesting thing to examine, is
not temporary, as above, but prolonged lack of stickiness in the load
balancer.
WADI will maintain 1+numReplicas copies of the session, no matter how
many different nodes may have to shelter the session during its lifetime.
Are you saying that each Terracotta node that shelters a session becomes
part of its replication group (i.e. has every change to that session
synchronously replicated to it) ? Can you expand ? Can you not place a
limit on group size ? If I churn nodes regularly, am I not going to end
up with a lot of unecessary replication ?
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.
"cheating" is a bit harsh...
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.
As I said - see the "apples-to-apples" straight replication test results
in the article.
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)
!! - I would hope that Terracotta doesn't always do one-to-all
replication and should point out that my reading of "One again, the cost
of keeping one session replica, i.e. the cost of keeping a copy of a
session on an another node than the one currently owning the session,
remains constant while the number of nodes in the cluster increases for
WADI." (see the Session Migration & Replication Test" observations),
indicates that WADI is running in a 1+1 configuration, that means it IS
replicating - each session has 1 (configurable) backup session off-node.
and therefore no SPoF either.
and a different test will more accurately reflect the relative
performance of the systems.
This is an interesting thread - but I think that there is a lot of
misunderstanding/miscommunication occurring that it would be useful to
clear up :-)
Jules
--Ari
