Mailing-List: contact users-help@qpid.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@qpid.apache.org
Received-SPF: pass (nike.apache.org: domain of kgiusti@redhat.com designates
 209.132.183.39 as permitted sender)
Date: Mon, 5 May 2014 08:45:26 -0400 (EDT)
From: Ken Giusti <kgiusti@redhat.com>
To: users@qpid.apache.org
Message-ID: <1377791250.523403.1399293926844.JavaMail.zimbra@redhat.com>
In-Reply-To: <5364B1A4.6020304@blueyonder.co.uk>
References: <5364B1A4.6020304@blueyonder.co.uk>
Subject: Re: Are there standard performance/benchmark tests for proton
 messenger?
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Thread-Topic: Are there standard performance/benchmark tests for proton
 messenger?
Thread-Index: +1U/HL1XMgfLyhBTiWpuvxhO6Qiccg==

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