On 12/08/2011 02:02 PM, Fraser Adams wrote:
Hi again Ted,
Actually there's one other thing that you may be able to help with (since you
clearly know about flow-control).
There's a little side project I'm working on when I get bored with the QMF stuff
where I'm looking at differences between the C++ qpid::client and
qpid::messaging APIs
So it's clear that the Qpid team are keen to deprecate the qpid::client API in
favour of qpid::messaging, which on face value seems really sensible given that
qpid::messaging is much simpler, abstracts away from the AMQP version and allows
Address strings to be shared (easy to test something in Java and run it live on
C++).
The issue that I have with this strategy relates to performance. So for example
I can use qpid-perftest to give the broker "a good hard kicking".
Now I've somewhat pulled qpid-perftest apart to distil the essence with the aim
of doing some direct comparisons. My problem is that I'm finding it really hard
to optimise qpid::messaging to the same extent as qpid::client has been for
qpid-perftest. My view is that it's not great to deprecate ::client until it can
be proved that ::messaging has the same (or better) performance - does that seem
a fair observation?
There are some new test clients written to the new API: qpid-send, qpid-receive
and qpid-cpp-benchmark (which orchestrates multiple qpid-send/receive clients) I
did some testing around the time we released the new API and got comparable
performance. You need to tweak a few values to get a fair comparison with
perftest. I compared:
qpid_cpp_benchmark --receive-option link:{reliability:unreliable} --repeat 5
--messages 100000 --no-timestamp
perftest --count 100000 -s
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
