qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fraser Adams <fraser.ad...@blueyonder.co.uk>
Subject Optimising Proton Messenger data transfers & msgr-send/msg-recv oddities
Date Fri, 31 Oct 2014 12:10:41 GMT
Hey all,
OK I'll 'fess up I have to admit that although I've been tinkering with 
Messenger for a while now I don't *really* understand some of the terms 
that get used such as credit, disposition, settlement. I think that I 
was OK with qpid::messaging's setCapacity stuff and how to use that to 
optimise prefetch and also using qpid::messaging link controls in the 
Address string to set/disable reliability but the settings on Messenger 
remain a mystery to me.

What really brought that home in my mind was when I started playing with 
the msgr-send and msgr-recv applications in <proton>/tests/tools/apps to 
try to figure what sort of throughput I might get with Messenger.

A while back Gordon was involved in a performance conversation and 
mentioned testing with the settings below
./msgr-recv -c 1000000
./msgr-send -c 1000000 -b 64

So sending/receiving a million 64 octet messages and seeing what the 
performance is - so far so good.

But I then tinkered around and hacked in some code to display the count 
for the sent and received messages and then did:

./msgr-recv -c 100
./msgr-send -c 100 -b 1000000

in other words sending & receiving 100 1MB messages - I actually used 
the large message size as much to slow things down as anything, but what 
I observed was that the 100 messages were all being sent before 
msgr-recv started to display any received count numbers.

When I looked at the usage I noticed the -p option "Send batches of # 
messages" and sure enough if I do
./msgr-send -c 100 -p 10 -b 1000000

I see msgr-recv catch up every 10 messages.

What I *think* is going on is that when the count in the internal 
Messenger queue (pn_messenger_outgoing(messenger)) exceeds the batch 
size it calls pn_messenger_send(messenger, -1);

But that makes me unclear in my mind what the differences between 
pn_messenger_put and pn_messenger_send actually are, I've certainly seen 
pn_messenger_put actually send messages. I realise that there's a 
comment "The message may also be sent if transmission would not cause 
blocking" but I'm not clear at exactly which point blocking would occur, 
I'm guessing that I'm noticing this because of my large messages? The 
problem of course is that if I use tiny little messages I can't actually 
see if any batching actually occurs or whether in the small message case 
pn_messenger_put merrily whizzes out the small messages without really 
needing pn_messenger_send to give them a helping kick.

Does that make sense? It'd be useful for someone who knows this stuff to 
explain how the Messenger store works and how the various API calls 
relate to credit, disposition & settlement (I'm pretty sure the latter 
relates to the tracker/window/accept/settle stuff but not so sure about 
the first two). I'd also quite like to know how this stuff relates to 
the capacity/reliability stuff on qpid::messaging.

Also I *think* that there is a problem with the python version of 
msgr-send.py I'd expect that to run more slowly than the C version, but 
when I did:

./msgr-recv.py -c 100
./msgr-send.py -c 100 -b 1000000

it returned more or less immediately and when I increase the -c value I 
appear to be seeing the same throughput irrespective of the value of the 
-b value. I've not really looked too deeply at the code but I wonder if 
that rings any bells for anyone?

Sorry if these things are obvious to the people who know, but I figured 
I probably wasn't the only one who didn't actually know this stuff and 
as I've got no shame I thought I'd raise my head above the parapet and 
expose my ignorance to the world :-)


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

View raw message