Re: [jgroups-dev] Screenshot of tree mesh structure

Mike Jensen wrote:
> Sorry for the delay, I been using this weekend to do some hiking before
> it starts to get really cold.
>
> We don't have a great test environment to do 100's of nodes. At work I
> was just running many jgroups instances within the same process to test
> the structures. I also did some performance based testing, but just
> verifying that the latency does not grow too much as the nodes grow (but
> i recognize the numbers themselves are not very valid, since they are
> from within the same process).

OK

> At home I have 20gigs of ram spread across 3 machines. I tend to use
> that for more real physical node testing. But even then I definitely
> can't reach 100 nodes. I might be able to squeeze a bit more, but I
> usually only run about 20 to 25 nodes here at my house.
>
> I will have to look at ns2, I have never tried it actually. 

I used it a long time ago. The issue is that it also simulates a 
distributed environment within a local host, so CPU, memory and 
bandwidth are shared, too, which isn't too great. It definitely isn't 
the same as having access to a large lab...

> Do you have any recommendations on setup to do good performance based 
> tests?

The question is what do you want to achieve ? If it is low latency 
delivery of messages, then  measure latency (as discussed by you below). 
If you want high throughput, but don't really care about latency, 
measure throughput. I guess your performance test needs to model the 
application you have in mind for treemesh; ie. online meetings. From my 
experience with webex, the toughest thing to do is screen sharing for 
online demos/webinars: it always takes a few seconds for the last member 
in the online community to see the updates to the screen. So maybe a 
good test would be to measure (min, max, median, avg) how long it takes 
for everyone to receive screen updates.

This is actually quite interesting, because a screen update might be 
both large (so throughput is important) and has to be disseminated 
around the network as quickly as possible.

> Here is how my simple test actually conducts itself:
> * Every 10 seconds every node sends a broadcast to the network which 
> includes it's current timestamp

OK

> * Once a node receives a broadcast from another node it responds,
> including the original timestamp, but marking the message as a return,
> and routing it to the original node through the mesh (which may be
> several hops).

OK

> * Once we receive the message back, we see how much time has passed, and
> who was the node who sent it back to us. We then record the time it
> took for node x to get our message, and send it back to us.

OK, that's exctly what I described above, cool !

Two potential changes could be to (1) have only 1 sender (presenter) and 
(2) send large data. I don't know how much data a screen generates, and 
I'd assume modern screen capturing software is good at compression (plus 
sends only deltas, e.g. MPEG-4)...

> It's a fairly high load situation due to the original message being a
> broadcast. But results were decent. I want to extend this to include
> much more information. For one thing, we need to track hops and we are
> not doing that currently.

Yep , another good measurement.




-- 
Bela Ban
Lead JGroups / Clustering Team
JBoss

------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Javagroups-development mailing list