qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ken Giusti <kgiu...@redhat.com>
Subject Re: Are there standard performance/benchmark tests for proton messenger?
Date Mon, 05 May 2014 12:45:26 GMT
Hi Fraser,

----- Original Message -----
> From: "Fraser Adams" <fraser.adams@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


Mime
View raw message