Hi Fraser, ----- Original Message ----- > From: "Fraser Adams" <[email protected]> > To: [email protected] > 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: [email protected] > For additional commands, e-mail: [email protected] > > -- -K --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
