qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject Re: Qpidmessaging client sends too many flows to ActiveMQ broker (vs qpidd broker)
Date Thu, 16 Oct 2014 19:46:17 GMT
On 10/15/2014 09:09 PM, Chuck Rolke wrote:
> 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.

I don't think there should be more that the number of received messages, 
in fact from a brief look I'd say its slightly fewer.

Are you using the latest code from trunk? There, the credit is updated 
for every message received, but how these are actually sent depends on 
the interleaving of the io thread and application thread.

Previously the io thread was woken up if needed for every credit 
increase. The difference between that and the current more optimal code 
with qpid::messaging against qpidd was pretty slight however. In other 
words the larger number of individual flow frames may not be the cause 
of the slowness.

What are the timings of the various frames? Are there any big gaps?

Is ActiveMQ configured to use tcp-nodelay?

Have you tried comparing e.g. proton messenger clients against both 
brokers to see if the same difference in time taken can be seen there?

> 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.

Nothing at the AMQP level should result in TCP retransmission (at least 
not at this volume).

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


Mime
View raw message