A few months back, Justin and I worked on a benchmark script that runs a couple of 'canned' tests against proton messenger. These tests use msgr-send/-recv under the covers. No qpidd involved - just proton messenger peer-to-peer using local loopback.
See https://github.com/kgiusti/proton-tools/blob/master/benchmark/README.txt Running that benchmark on my fedora 18 laptop (dual-core Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz, 8 gigs DDR 3, no swap. "lightly" loaded) using the proton 0.5 release gives me these results: [kgiusti@t530 benchmark (master)]$ ./msgr-benchmark LATENCY (msecs) low mean high Loopback (64byte) 1.2 1.2 1.2 Large Msg (2Mbyte) 20.1 20.1 20.2 THROUGHPUT (msgs/sec) low mean high Loopback (64byte) 31801.6 32347.7 33193.9 Large Msg (2Mbyte) 97.1 98.1 98.7 Though for a majority of the test run (about 5 minutes), neither msgr-send nor msg-recv broke 60% cpu utilization. The Loopback (64byte) test is roughly like the test Gordon ran. It actually runs msgr-recv/send like this: [kgiusti@t530 benchmark (master)]$ ps -fe | grep msgr kgiusti 4589 2785 0 09:33 pts/0 00:00:00 python ./msgr-benchmark kgiusti 4678 4589 62 09:34 pts/0 00:00:04 msgr-recv -X READY -a amqp://~0.0.0.0:54688 -c 1000000 -b 2048 -t 60 -R kgiusti 4679 4589 63 09:34 pts/0 00:00:04 msgr-send -a amqp://0.0.0.0:54688 -c 1000000 -b 64 -p 1024 -R -t 60 But in this case the receiver is echoing back each message, which I suspect causes the lower results as compared to Gordon's. I really should add an additional test that does the one-way peer pattern (along with multi-link, ssl, etc...) -K ----- Original Message ----- > From: "NimbusParc" <[email protected]> > To: [email protected] > Sent: Tuesday, October 1, 2013 6:46:15 AM > Subject: Re: proton messenger performance (was Re: QPID AMQP Performance test) > > +1 > > Gordon Sim wrote > > On 09/30/2013 05:57 PM, amitg90 wrote: > >> Hi All, > >> > >> i am new to QPID, after downloading the software from website, i used the > >> sample example code (recv.c and send.c) and modified on send side to > >> continuouly send 64 bytes packets from machine A and on recevie side on > >> machine B grabbing the packet and checking how much packets i received > >> per > >> sec and i am not able to see more than 18000 packets per sec (throughput > >> 10Mbps). > >> > >> being a 1Gbps link between two machines i was hoping for more throughput > >> coming out of it.. > >> > >> i ran standard TCP performance test and it get close to 800Mbps > >> throughput. > >> > >> can someone please suggest if there is something obvious that i am > >> missing > >> or there exist some performance script which help me understand what is > >> causing low throughput.. > > > > There are two test programs that report throughput and latency for > > different scenarios. The executables are built under > > <build> > > /tests/tools/apps/c/ and are called msgr-send and msgr-recv. > > > > E.g. for a one-way test, start > > > > /tests/tools/apps/c/msgr-recv -c 1000000 > > > > then in another console: > > > > /tests/tools/apps/c/msgr-send -c 1000000 -b 64 > > > > The message size is controlled with the -b option. You can vary the > > batch size for send with -p option. You can also run a two way test, > > where the receiver echoes the messages back using the -R option to each. > > By default messages are sent presettled, you can change that by setting > > a non zero outgoing window with the -w option. > > > > On my laptop, over loopback, I get about 50k 64 byte msgs/sec using the > > default batch size of 1024. With a batch size of 1, that drops to about > > 25k msgs/sec. > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: > > > [email protected] > > > For additional commands, e-mail: > > > [email protected] > > > > > > -- > View this message in context: > http://qpid.2158936.n2.nabble.com/QPID-AMQP-Performance-test-tp7598833p7598856.html > Sent from the Apache Qpid users mailing list archive at Nabble.com. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- -K --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
