I'm working on comparing AMQP 1.0 clients with different brokers. In this case
I have ActiveMQ 5.10 and Qpidd 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 receiver might never have to wait doing a
fetch because the receiver's capacity will prefetch the messages.
The results:
Each broker ran from a fresh boot. Only one broker ran at a time.
With Qpidd the client gets through the 400 messages in 8 +/- 3 mS. The AMQP
transfer-to-flow ratio is very high and efficient.
With ActiveMQ 5.10 the clients takes 260 +/- 60 mS. The AMQP transfer-to-flow
ratio is much lower. Additionally, the client sends frames to the host where
the payload is nothing but a dozen flow performatives (see frame 138 below).
This is the exact same client that worked so well with Qpidd.
To visualize the traffic please see:
http://people.apache.org/~chug/adverb_unreliable_400_50/_unreliable_qpidd_400_batched_50.html
http://people.apache.org/~chug/adverb_unreliable_400_50/_unreliable_amq5.10_400_batched_50.html
Discussion:
1) Is this a real issue, and if so with which module?
It looks like the qpidmessaging client spits out a flow for each message it
receives
from the broker and then some. That makes sense until the back-to-back flow
frames
start piling up. In one trace with 2000 messages I saw 700 consecutive flow
frames from the client to
the broker but this is not repeatable.
Both brokers wind up transferring the same payload in the end. But maybe if the
client did things a little differently the ActiveMQ broker could do it more
quickly.
2) Another late observation in the ActiveMQ broker trace is:
◊ ◊◊ Frame 67 [::1]:47813 -> [::1]:5672 8.478287 [transfer [0,1] (47) ..
transfer [0,1] (99)]
◊ ◊◊ Frame 68 [::1]:47813 -> [::1]:5672 8.487341 [transfer [0,1] (47) ..
transfer [0,1] (99)]
Here the client is sending the same batch of messages (47..99) twice with the
second being a
TCP Retransmission and a lost 10mS between the two. This same retransmission
is in the
two traces from different runs that I've saved so it is somewhat repeatable.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
