Are there standard performance/benchmark tests for proton messenger?

[Fraser Adams <fr...@blueyonder.co.uk>]

Hey all,
What sort of performance testing and benchmarking do you guys do? The 
closest that I've noticed to tests that look like they could do this 
sort of thing are the msgr-send and msg-recv examples in 
tests/tools/apps is that about right or does anyone use anything else?

If people have their own useful little "private" benchmark suites is 
there a reason why they couldn't be committed?

I'm keen to see this sort of thing for some good examples of how to 
squeeze the  best performance out of Messenger (and to help me compare 
with qpid::messaging).

I also keep getting bitten by the CMake default being an unoptimised 
build, TBH I really hate that it does that :'( !

Cheers,
Frase

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

Re: Are there standard performance/benchmark tests for proton messenger?

[Ken Giusti <kg...@redhat.com>]

Hi Fraser,

----- Original Message -----
> From: "Fraser Adams" <fr...@blueyonder.co.uk>
> To: users@qpid.apache.org
> Sent: Saturday, May 3, 2014 5:06:44 AM
> Subject: Are there standard performance/benchmark tests for proton messenger?
> 
> Hey all,
> What sort of performance testing and benchmarking do you guys do? The
> closest that I've noticed to tests that look like they could do this
> sort of thing are the msgr-send and msg-recv examples in
> tests/tools/apps is that about right or does anyone use anything else?
> 
> If people have their own useful little "private" benchmark suites is
> there a reason why they couldn't be committed?
> 

A while back I built a simple benchmark tool [0] that wraps the msgr-send/msgr-recv commands with some logic that tries to 'pretty up' the output.  And it uses a hardcoded set of msgr-send/recv parameters, so each run of the benchmark executes the same code.

The problem: even though I spent some time hand-tuning the benchmark parameters, I still couldn't get either msgr-send/recv to anywhere near 100% cpu (each is single threaded, btw), so this benchmark really doesn't push the code to the limit.

[0] https://github.com/kgiusti/proton-tools/tree/master/benchmark

> I'm keen to see this sort of thing for some good examples of how to
> squeeze the  best performance out of Messenger (and to help me compare
> with qpid::messaging).
> 
> I also keep getting bitten by the CMake default being an unoptimised
> build, TBH I really hate that it does that :'( !
> 

+1 - Personally, I'd like to see the default CMAKE_BUILD_TYPE be RelWithDebInfo.  Not only because I'm old and forget to turn on optimization, but IIRC the GNU compiler doesn't do path analysis unless optimization is turned on.  I'd like to see this default picked up for qpid/C++ too, if possible.   But I suspect larger brains than mine have already thought about this and came to a different conclusion.


> Cheers,
> Frase
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
> 
> 

-- 
-K

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org