3 ms·

$ time seq 5000000 >/dev/null 1.10s user 0.00s system 99% cpu 1.107 total There, my Mac Mini can push ~5M msgs/second!!1one Do I get a pony now? Seriously,

by moe 14y ago

$ time seq 5000000 >/dev/null 1.10s user 0.00s system 99% cpu 1.107 total There, my Mac Mini can push ~5M msgs/second!!1one Do I get a pony now? Seriously, what is this doing on HN and what on earth are people discussing? If you want to brag with benchmarks then how about providing at least a remote clue about what you are measuring...

pretoriusB 14y ago
>Do I get a pony now? No, but you get an award for snarky 4-chan like behavior.
- moe 14y ago
  That's fine. I'll keep improving my code, perhaps I can get the Pony when it crosses the 10M/sec barrier.
derekcollison 14y ago
The simple benchmark is testing throughput of a messaging system, specifically a new server written in Go. Both the client and server are on the same machine, but going over a tcp/ip socket. The Pub benchmarks send messages and then make sure the connection is flushed, meaning all messages have been completely processed by the server. Processing in this case means framing, protocol and routing logic. The PubSub versions test sending and receiving all the messages back in the client, with a few variations on using multiple connections and distributed queuing.
- moe 14y ago
  Thanks, that's much more informative! I'm looking forward to the full suite being released so we can repeat the tests and see how it fares under real-world conditions with different message-sizes etc. Sorry for the snark in my initial comment but I found this gist really lacking (akin to those press releases where $vendor brags about some arbitrary figure without providing any details). I do like the simplicity of NATS and look forward to a fast server implementing it. However for something like a MQ where performance is the key-metric and highly dependent on the chosen workload one really shouldn't throw around numbers without backing them up thoroughly - that only hurts credibility. Please take the write-ups by the RabbitMQ guys as a guide, who publish the source-code for all their benchmarks and go to great lengths explaining them: http://www.rabbitmq.com/blog/2012/04/25/rabbitmq-performance-measurements-part-2/ http://www.rabbitmq.com/blog/2012/04/25/rabbitmq-performance...

by moe 14y ago

pretoriusB 14y ago

>Do I get a pony now? No, but you get an award for snarky 4-chan like behavior.

moe 14y ago
That's fine. I'll keep improving my code, perhaps I can get the Pony when it crosses the 10M/sec barrier.

derekcollison 14y ago

The simple benchmark is testing throughput of a messaging system, specifically a new server written in Go. Both the client and server are on the same machine, but going over a tcp/ip socket. The Pub benchmarks send messages and then make sure the connection is flushed, meaning all messages have been completely processed by the server. Processing in this case means framing, protocol and routing logic. The PubSub versions test sending and receiving all the messages back in the client, with a few variations on using multiple connections and distributed queuing.

moe 14y ago
Thanks, that's much more informative! I'm looking forward to the full suite being released so we can repeat the tests and see how it fares under real-world conditions with different message-sizes etc. Sorry for the snark in my initial comment but I found this gist really lacking (akin to those press releases where $vendor brags about some arbitrary figure without providing any details). I do like the simplicity of NATS and look forward to a fast server implementing it. However for something like a MQ where performance is the key-metric and highly dependent on the chosen workload one really shouldn't throw around numbers without backing them up thoroughly - that only hurts credibility. Please take the write-ups by the RabbitMQ guys as a guide, who publish the source-code for all their benchmarks and go to great lengths explaining them: http://www.rabbitmq.com/blog/2012/04/25/rabbitmq-performance-measurements-part-2/ http://www.rabbitmq.com/blog/2012/04/25/rabbitmq-performance...