You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Gordon Sim <gs...@redhat.com> on 2013/10/01 12:08:22 UTC
proton messenger performance (was Re: QPID AMQP Performance test)
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.
Rafi, Ken, can either of you give an indication of what you would expect
to see?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: proton messenger performance (was Re: QPID AMQP Performance test)
Posted by Gordon Sim <gs...@redhat.com>.
On 10/01/2013 02:59 PM, Ken Giusti wrote:
> 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:
That build option makes a big difference for me, with that I see just
under 100k msgs/sec of 64 bytes each using default batching and credit
options.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: proton messenger performance (was Re: QPID AMQP Performance
test)
Posted by Ken Giusti <kg...@redhat.com>.
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" <kg...@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" <ni...@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
Re: proton messenger performance (was Re: QPID AMQP Performance
test)
Posted by Ken Giusti <kg...@redhat.com>.
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" <ni...@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
Re: proton messenger performance (was Re: QPID AMQP Performance
test)
Posted by NimbusParc <ni...@yahoo.in>.
+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