qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From 郑勰 <zhengxie...@icloud.com>
Subject Re: REQEST FEEDBACK Re: How to test the performance quid c++ broker
Date Fri, 25 Jul 2014 16:27:37 GMT

Wow, I didn’t expect a little question would raise a lively discussion.
Truth be told, my boss is inclined not to use quid  because of low throughout. We expect sent
messages and received messages should be at least 200,000 per second.However, I am really
trying to convince myself to obtain this goal.
I want to know all of your performance result.

Thanks!












在 2014年7月26日,上午12:13,Alan Conway <aconway@redhat.com> 写道:

> On Fri, 2014-07-25 at 16:47 +0100, Fraser Adams wrote:
>> 
>> On 25/07/14 15:30, Alan Conway wrote:
>>> On Thu, 2014-07-24 at 17:31 +0100, Fraser Adams wrote:
>>>> On 24/07/14 13:59, Alan Conway wrote:
>>>>> Very important point I forgot to mention: are you doing a release
>>>>> build?
>>>>> 
>>>>> cmake -DCMAKE_BUILD_TYPE=Release
>>>>> 
>>>>> That makes a big difference. It enables optimization flags for the C++
>>>>> compiler. The default is not optimized.
>>>>> 
>>>> Alan,
>>>> I've mentioned this before, but I remain unconvinced that the default 		
																																																																																									
																																																																																									
																																																			
>>>> should be for an unoptimised build. I totally realise that seems to be
>>>> "the CMake way", but it always used to be the case under automake that
>>>> the default was something reasonably optimised.
>>>> 
>>>> If it turns out that your suggestion is indeed the cause of the
>>>> discrepancy I think that would back up the view that *at the very least*
>>>> the documentation for doing the build should mention this and if there
>>>> is still a general view to default to the unoptimised I actually think
>>>> that the CMake for qpid and proton should display a warning to remind
>>>> users that they are using an unoptimised build.
>>> I agree (not sure why I didn't before, probably not paying attention.)
>>> The default actually isn't any of the advertised build types (Debug,
>>> Release etc.) it's a "just ignore opt/debug flags" build which is not
>>> especially useful for anything. I never use it.
>>> 
>>> So I vote for making the default build type Release. Someone who finds
>>> performance sucks is more likely to leave without asking questions than
>>> someone who has trouble with their debugger (and since the default
>>> doesn't set -g anyway that doesn't appear to be a problem.)
>>> 
>>> Any counter opinions? (as always, I assume silence is consent :)
>>> 
>>> Cheers,
>>> Alan.
>>> 
>>> 
>> Thanks for this discussion Alan!
>> 
>> My vote would be to default to the most optimised/operational-quality 
>> build possible. My reasoning being that I suspect that *most* people (if 
>> not all) coming in fresh would have a not unreasonable expectation that 
>> qpid would "just work" and moreover would "just work" at its best. Your 
>> "leave without asking questions" point is something that as a community 
>> I believe that we must have high on our list of things to avoid!
>> 
>> If the RelWithDebInfo is exactly as fast then that's probably OK, but if 
>> I'm honest I believe that the default should really be to build 
>> something that a user might want to ship in an operational 
>> mission-critical system and I'm not personally keen on the idea of 
>> shipping with debug symbols or anything else that could potentially 
>> increase an attack vector.
>> 
>> I'm more than happy that we supply documentation that tells users how to 
>> enable debugging etc. but all of that is really developer focussed IMHO 
>> and I think that the default should be first and foremost user focussed.
> 
> I'm inclined to agree that the default should be user focused rather
> than developer focused. On the gcc/intel/RHEL6 system I benchmarked
> Release is slightly better but not much. However I can't say if that's
> the case for other compiler/OS/hardware combinations. Assuming its
> implemented correctly one would assume that Release is going to be the
> most release-worthy in general if there is a tradeoff to be made.
> 
> Any further thoughts from the RelWithDebInfo fans?
> 
> Cheers,
> Alan.
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message