Just to follow up - running a single-direction peer-to-peer loopback against 0.5 (compiled w/CMAKE_BUILD_TYPE=Release), I get the following:
[kgiusti@t530 benchmark (master)]$ msgr-recv -X READY -a amqp://~0.0.0.0:9999 -c 1000000 -b 2048 -t 60 & [1] 5148 READY [kgiusti@t530 benchmark (master)]$ msgr-send -a amqp://0.0.0.0:9999 -c 1000000 -b 64 -p 1024 -t 60 Messages sent: 0 recv: 1000000 Total time: 8.964000 sec Throughput: 0.000000 msgs/sec Latency (sec): 0.004000 min 0.029000 max 0.008092 avg Messages sent: 1000000 recv: 0 Total time: 8.997000 sec Throughput: 111148.160498 msgs/sec Latency (sec): 0.000000 min 0.000000 max 0.000000 avg In this case, the sender is easily hitting 100% cpu, receiver about 70%. I think the reason I'm seeing better perf in these tests than Gordon's result is due to the amount of credit and send "batch" sizes used above. By default, msgr-recv uses the -1 credit flag to pn_messenger_send(), which isn't optimal in this case. For the above test, the "-b 2048" parameter grants 2048 credits to the link, which results in better performance. The "-p 1024" argument to msgr-send may also help - it instructs msgr-send to "batch" (ie, call pn_messenger_send()) 1024 times for each call to pn_messenger_put(). I'll update the benchmark to add this type of test. -K ----- Original Message ----- > From: "Ken Giusti" <[email protected]> > To: [email protected] > Sent: Tuesday, October 1, 2013 9:42:15 AM > Subject: Re: proton messenger performance (was Re: QPID AMQP Performance test) > > 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] > > -- -K --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
