[Spread-users] spread performance testing
Ryan Caudy
caudy at jhu.edu
Mon Apr 19 17:21:17 EDT 2004
Hi again,
I just realized one more thing, while taking a second look at your test
results. You were using a write-only flooder and a read/write
flooder... which changes somewhat the interpretation of the results.
You were actually sending ~20Mbytes over the network, not 10. However,
its hard to really judge performance in this case, because of the way
the flooder application works with these settings. You can do something
that lets you get measurable performance if you run 1 read/write flooder
and several read-only flooders. There are still several sources of
error, in such a test, however.
To do something a bit more interesting, you might adjust the flooder
application to wait until a configurable number of flooders have
connected to spread and joined the right group. Start the timer,
sending, and receiving when the last expected join is detected. Timing
from this interval until the last flooder receives the number of
messages expected might give you pretty valid results. It would also be
interesting to see what different service types than RELIABLE can produce.
I haven't done any detailed performance tests, but it's possible someone
else on the list has. I'm not sure exactly what you mean by groupware,
but I think you might be talking about things like the JMS4Spread project.
Cheers,
Ryan
Jayesh Maganlal wrote:
> Hi,
>
> Thank you for the quick reply. I guess the same, there is something with the
> network. I'll check on that.
>
> Another thing, have you or anyone else conducted a study on the performance
> of Spread with regards to bandwidth utilization, delay/latency, reliability
> comparison to existing network. I'm doing a study on the performance of
> groupware application that uses Spread (reliable multicasting) compared to
> existing broadcast and unicast, so before i go into details of the study, i
> just want to make sure that i'm heading the right way, so that at the end i
> can have a result that shows significant improvements and hope to contribute
> this findings to all Spread researchers.
>
> Does anyone know if anybody has implemented Spread in groupware
> applications?
>
> Regards,
> Jayesh
>
>
> ----- Original Message -----
> From: "Ryan Caudy" <caudy at jhu.edu>
> To: "Jayesh Maganlal" <calicatel at maxis.net.my>
> Cc: "spread-users" <spread-users at lists.spread.org>
> Sent: Tuesday, April 20, 2004 3:11 AM
> Subject: Re: [Spread-users] spread performance testing
>
>
>
>>I just did similar tests to those I described, and to those you showed
>>results from. The following are the results:
>>
>>[[Tests similar to yours.]]
>>
>>$ java Flooder -p 9903 -ro
>>Only receiving messages
>>Completed 1000 messages
>>Completed 2000 messages
>>Completed 3000 messages
>>Completed 4000 messages
>>Completed 5000 messages
>>Completed 6000 messages
>>Completed 7000 messages
>>Completed 8000 messages
>>Completed 9000 messages
>>Completed 10000 messages
>>Time: 3061ms (24.92 Mbps)
>>
>>These results are meaningless... this process waits for a while before
>>I start the second process.
>>
>>$ java Flooder -m 10000 -b 1024 -p 9903
>>Starting multicast of 10000 messages, 1024 bytes each.
>>Completed 1000 messages
>>Completed 2000 messages
>>Completed 3000 messages
>>Completed 4000 messages
>>Completed 5000 messages
>>Completed 6000 messages
>>Completed 7000 messages
>>Completed 8000 messages
>>Completed 9000 messages
>>Completed 10000 messages
>>Time: 1625ms (96.15 Mbps)
>>
>>These results show worse performance than my other tests (below), but my
>>best guess is just that there is a performance hit to using Java. Note
>>that (a) I used a read/write daemon, not a write-only, for accurate
>>results, and (b) the output Mbps value above is twice what the real
>>number should be, because of a funky calculation in the Java Flooder.
>>
>>[[Tests similar to mine.]]
>>
>>$ time spflooder -s 9903 -ro
>>flooder: connecting to 9903
>>flooder: Only receiving messages
>>flooder: completed 1000 messages of 1000 bytes
>>flooder: completed 2000 messages of 1000 bytes
>>flooder: completed 3000 messages of 1000 bytes
>>flooder: completed 4000 messages of 1000 bytes
>>flooder: completed 5000 messages of 1000 bytes
>>flooder: completed 6000 messages of 1000 bytes
>>flooder: completed 7000 messages of 1000 bytes
>>flooder: completed 8000 messages of 1000 bytes
>>flooder: completed 9000 messages of 1000 bytes
>>flooder: completed 10000 messages of 1000 bytes
>>flooder: completed multicast of 10000 messages, 1000 bytes each.
>>
>>real 0m4.053s
>>user 0m0.010s
>>sys 0m0.120s
>>
>>These results (for a read-only flooder started first) are meaningless,
>>as mentioned above.
>>
>>$ time spflooder -s 9903 -m 10000 -b 1000
>>flooder: connecting to 9903
>>flooder: starting multicast of 10000 messages, 1000 bytes each.
>>flooder: completed 1000 messages of 1000 bytes
>>flooder: completed 2000 messages of 1000 bytes
>>flooder: completed 3000 messages of 1000 bytes
>>flooder: completed 4000 messages of 1000 bytes
>>flooder: completed 5000 messages of 1000 bytes
>>flooder: completed 6000 messages of 1000 bytes
>>flooder: completed 7000 messages of 1000 bytes
>>flooder: completed 8000 messages of 1000 bytes
>>flooder: completed 9000 messages of 1000 bytes
>>flooder: completed 10000 messages of 1000 bytes
>>flooder: completed multicast of 10000 messages, 1000 bytes each.
>>
>>real 0m1.115s
>>user 0m0.010s
>>sys 0m0.290s
>>
>>As you can see, these results for the read/write flooder are similar to
>>those I mentioned before, although slightly worse.
>>
>>I would expect some performance decrease, since you are using Java and
>>Windows, but not one as significant as what you showed. My tests, both
>>Java and C, are on Linux kernal 2.4.3-12smp. It's possible that you
>>have problems of some sort on your network. To diagnose this, you might
>>consider looking at status output from spmonitor.
>>
>>Cheers,
>>Ryan
>>
>>Jayesh Maganlal wrote:
>>
>>
>>>Hi Ryan and all,
>>>
>>>Need urgent help.
>>>
>>>Referring to your (Ryan's) mail below, i conducted a test on my own with
>
> the
>
>>>same scenario that you mentioned, With two spread daemons running on
>>>different machines (on a 100 Mbit ethernet), a receive-only spflooder on
>
> one
>
>>>machine, and a send/receive spflooder on the other, I sent 10000 packets
>
> of
>
>>>1000 bytes each. The results that i got is no where near what you
>
> mentioned.
>
>>>Look at the output below. I don't understand why is it slow. I can do
>
> the
>
>>>same test using "spsend" and "sprecv" around 1sec. Could it be because
>
> of my
>
>>>configuration settings that i have. Below is the configuration that i'm
>>>using. Please advice. Looking forward for your reply.
>>>
>>>Output:
>>>===================================================
>>>C:\spread-bin-3.17.1\win>java Flooder -m 10000 -b 1024 -wo
>>>Starting multicast of 10000 messages, 1024 bytes each (self discarding).
>>>Completed 1000 messages
>>>Completed 2000 messages
>>>Completed 3000 messages
>>>Completed 4000 messages
>>>Completed 5000 messages
>>>Completed 6000 messages
>>>Completed 7000 messages
>>>Completed 8000 messages
>>>Completed 9000 messages
>>>Completed 10000 messages
>>>Time: 6409ms (12.18 Mbps) <<<< Time taken to send 6.4 seconds
>>>
>>>C:\spread-bin-3.17.1\win>java Flooder -m 10000 -b 1024
>>>Starting multicast of 10000 messages, 1024 bytes each.
>>>Completed 1000 messages
>>>Completed 2000 messages
>>>Completed 3000 messages
>>>Completed 4000 messages
>>>Completed 5000 messages
>>>Completed 6000 messages
>>>Completed 7000 messages
>>>Completed 8000 messages
>>>Completed 9000 messages
>>>Completed 10000 messages
>>>Time: 7051ms (22.15 Mbps) <<<< Time taken to send 7.051
>>>===================================================
>>>
>>>Spread Config file (comments are not in the config file):
>>>=====================================
>>>Spread_Segment 192.168.1.255:4803 {
>>> Test02 192.168.1.100 <<<<<<<<<<<<<<<<<<-------- receiver machine
>>> Test04 192.168.1.10 <<<<<<<<<<<<<<<<<---------sender machine
>>>}
>>>
>>>
>>>Thank you.
>>>Regards,
>>>Jayesh
>>>
>>
>>--
>>Ryan W. Caudy
>>Center for Networking and Distributed Systems
>>Department of Computer Science
>>Johns Hopkins University
>
>
>
>
> _______________________________________________
> Spread-users mailing list
> Spread-users at lists.spread.org
> http://lists.spread.org/mailman/listinfo/spread-users
>
--
Ryan W. Caudy
Center for Networking and Distributed Systems
Department of Computer Science
Johns Hopkins University
More information about the Spread-users
mailing list