[Spread-users] Performance metrics

[Pierce, J. Will]

Hey folks,

 

I'm wondering what the maximum rate of messages/sec people are seeing on
their spread networks.  I've used the spflood utility to test a few
scenarios, and so far the best throughput I've seen on production
quality hardware ranges from 35,000 - 101,000 spread messages/second.  I
can't really tell if these numbers are high or low compared to other
users...  The basics of this test are: 3 nodes in the cluster, on gigE
on a switch, with plenty of CPU.  The limiting factor seems to be CPU
usage by the spread daemon itself.  It appears to be a single-threaded
process, so the spflood testing causes spread to consume 100% cpu. The
bottleneck is messages/sec, not bytes/sec, for small message sizes.

 

Are there any recent measurements showing performance statistics on
modern CPUs and networking gear with various message sizes and # of
listeners, for different environments of LAN, and LAN+WAN segments?

 

>From what spflood testing is showing, so far, I believe the limiting
factor for me is not bandwidth, but messages/sec (pkts/sec).  I suspect
I will have to use larger batched messages in my application to avoid
maxing out CPU on spread messages/sec (if I directly map application
message/sec to spread message/sec.)

 

I'm also interested in the performance of spread in the face of some
known likely failure conditions, like a single node being down, or the
leader down going down.  Aside from a temporary spike in message
latency, I'm really interested in what effect a single dead-node will
have on overall throughput (msgs/sec) in a spread network.  This
obviously translates directly to real world failure cases.

 

What is your experience and do you have any tips to help avoid
overwhelming spread, and how to best implement clients (rotoring and
such) to reduce impact of likely failure cases?

 

Just curious... Thanks everyone, and thanks to Yair and Co. for
providing such an amazing framework like Spread.

 

- Will

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.spread.org/pipermail/spread-users/attachments/20100321/22d379f1/attachment.html