I think we can extend qpid_send and qpid_recv to do most of the things that
perftest and latencytest do. Interested in any ideas on the topic.
Here's what I propose:
Additional qpid_send options:
--report=Y/N: report sender throughput on exit.
--report-interval=SECS: print throughput report every N seconds.
--timestamp=Y/N: timestamp each message.
--rate=MSGS/SEC: send at this rate, 0 means fast as possible.
--padding=BYTES: add this much padding to messages.
--time-limit=SECS: stop after this time, 0 means no limit.
--max-noreply=N: don't send more than N messages without receiving a reply.
Creates a reply queue and sets reply_to on every N/2 messages.
Additional qpid_recv options:
--report=Y/N: report latency and throughput statistics on exit.
Latency is only calculated for messages with a timestamp.
--report-interval=SECS: print latency and throughput statistics every N seconds.
New qpid_recv behavior: if reply-to is set, echo the message to that address.
The --max-noreply=N option is a simple form of end-to-end throughput. The sender
sets reply-to on every N/2 messages. It won't send more than N messages beyond
the last message that was replied to. The receiver replies whenever reply-to is set.
Multiple instances of sender & receiver can be mixed and matched however you
want, to measure e.g. shared queue, pub-sub etc. scenarios. I'm deliberately
avoiding the do-everything swiss army knife approach of perftest, that results
in an overly complex test that is not as flexible as the separate
sender/receiver approach.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
