Alan Conway wrote:
I'm happy to report that after appropriate tuning of the tests, the new
API seems to perform as well as the old for basic thruput/latency tests.
Detailed results attached.
The main change since my previous mail on the subject was to disable
setting sequence number and timestamp properties and compare results
with a reliable receiver - all fair changes since they are equivalent to
what perftest does.
There is one mystery with the new api: an unreliable sender is _slower_
than reliable sender. As far as I can see by inspection and profiling,
an unreliable sender does strictly less work than reliable one so this
puzzles me. If anyone has a theory I'd love to hear it!
Have you isolated that it is actually the sender that is slower, or is
it that overall throughput is slower when unreliably sending?
If it is the latter it doesn't seem entirely implausible since overall
throughput is generally gated by consumption, which means a more
efficient producer (i.e. the unreliable one) might actually result in
slower overall throughput because it simply ends up filling the queue
more quickly.
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
