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 :-)
Cheers,
Frase
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
