I'm working on comparing AMQP 1.0 clients with different brokers. In this case
I have ActiveMQ (5.10) and Qpidd (trunk, proton at about 0.8) brokers on a
Fedora 19 localhost. For the client I have a qpidmessaging client test that
moves unreliable messages.
The test client program:
For the full source please see
http://people.apache.org/~chug/adverb_unreliable_400_50/hello_world.cpp
0. Uses 400 total messages with a 'batch' size of 50.
1. Creates a connection to:
"chuck; {create:always, link: {reliability:unreliable}}"
2. Creates a sender and receiver each with capacity of 100.
3. Sends a batch to the broker
4. Loops sending and receiving batches of messages
5. Receives the final batch.
The idea is to prime the broker with a batch of messages. Then send and
receive batches so that the client receiver might never have to wait doing a
fetch because the receiver's capacity will prefetch the messages.
Results:
1.
http://people.apache.org/~chug/adverb_unreliable_400_50/unreliable2_amq5.10_400_50.html
2.
http://people.apache.org/~chug/adverb_unreliable_400_50/unreliable2_amq5.10_400_50_tcpnodelay.html
3.
http://people.apache.org/~chug/adverb_unreliable_400_50/unreliable2_qpidd_400_50.html
Notes:
1. Run 1 was ActiveMQ 5.10 with no options.
2. Run 2 was ActiveMQ 5.10 with amqp transport.tcpNoDelay=true
3. Run 3 was Qpidd (0.30+) with no options (tcpNoDelay=true by default).
4. Each trace has four consecutive runs of the test program on a fresh restart
of the broker.
5. Statistics:
Elapsed time (mS) Over-the-wire frames
------------------ --------------------
Run 1, ActiveMQ - stock : 261, 209, 209, 208 85, 73, 70, 68
Run 2, ActiveMQ - tcpNoDelay : 201, 180, 146, 123 459, 484, 459, 457
Run 3, Qpidd - stock : 16, 17, 17, 18 50, 55, 44, 73
It's notoriously hard to describe what a protocol is doing to make it
faster/slower in one case or another. The trace web pages are an attempt at
doing just that and are generated from post-processed Wireshark decodes. I hope
this helps.
-Chuck
