So I've been looking at running Qpid's C++ broker and a client on an
embedded target.
I need to transit some traffic from JMS clients and brokers on workstations
and route it elsewhere via an embedded platform.
One thing I've found is that some fairly innocuous looking Qpid receiver
code running under the C++ API can take orders of magnitude longer to run.
Some experiments just locally on a Ubuntu Linux box (12.04 LTS) reveal:
If I pre-fill a queue with 5000 * 1024-byte messages from a JMS source
client,
a local JMS consumer will take approximately 3s to drain it.
However, if, instead, I have some C++ Qpid Messaging API client just doing:
while(1)
{
receiver.fetch();
session.acknowledge();
}
on the same queue, this takes nearly 200s to consume the same data!!
Playing around with 2 parameters yields significant improvement - if I setup
the receiver with:
receiver.setCapacity(100),
and then ONLY session.acknowledge() once every 100 messages,
the C++ client's message consumption drops massively to just 250ms.
This leads me to ask the question:
What should the C++ code look like in order to most closely imitate what the
JMS equivalent is doing?
i.e.
The JMS client has an AUTO_ACKNOWLEDGE parameter on the session creation.
How can the C++ code
mimic this behaviour/performance?
And how does the C++ receiver capacity fit into the same equation??
Finally, when running the C++ qpidd broker on the embedded target, CPU usage
is really high when firing
a similar quantity of message data at it. An embedded broker daemon and
consuming client will quite happily max
out the CPU just for the task of messaging. I certainly don't see
tens-of-thousands of messages-per-second throughput. More like tens or
hundreds at best.
Are there options, strategies or guidelines for running such an arrangement
in a more efficient and less computationally intensive
manner (either in build-time options or command-line execution of the
broker, or structuring the client code in a specific way)??
Thanks for all practical advice!
Mark.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
