qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ken Giusti <kgiu...@redhat.com>
Subject Re: proton messenger performance (was Re: QPID AMQP Performance test)
Date Tue, 01 Oct 2013 13:59:25 GMT
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" <kgiusti@redhat.com>
> To: users@qpid.apache.org
> 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" <nimbusparc@yahoo.in>
> > To: users@qpid.apache.org
> > 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:
> > 
> > > users-unsubscribe@.apache
> > 
> > > For additional commands, e-mail:
> > 
> > > users-help@.apache
> > 
> > 
> > 
> > 
> > 
> > --
> > 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: users-unsubscribe@qpid.apache.org
> > For additional commands, e-mail: users-help@qpid.apache.org
> > 
> > 
> 
> --
> -K
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
> 
> 

-- 
-K

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org


Mime
View raw message