Trunk Version - RHMD Vs QPID - And General Performence

[mark yoffe <ma...@gmail.com>]

Hi

I am currently involwed in a project using rhmd
as far as i understand from threads posted here
rhmd is the trunk version of qpid with an extended plugin - used for
persistency which is based on Berkley DB
and does not support apache license that is why it is not part of the
standard destribution
(please corect me if i am wrong)

several questions

1 - Is there any reason to use the rhmd version does it offer any "extra"
features/benefits that are not part of qpidd?
2 - Is it problematic to use the trunk version in its current form ?
3 - what is the "future" plan for the trunk version (c++ broker specificlly)
, when is the Beta, or RC's  planned as i currently see most efforts are
directed towords M2.1(maybe M2.2
     as M2.1 just released officially )?
4 - If i am looking for the promissed Qpidd performence capabilities ( i
found reports on 300K messages per second ), what version should i use? does
the version affect performence?
     and if so how high/low does the trunk score in that field ?


Thanks In advance
Yoffe Mark

Re: Trunk Version - RHMD Vs QPID - And General Performence

[Robert Greig <ro...@gmail.com>]

2008/5/18 mark yoffe <ma...@gmail.com>:

> I want to to create a configuration of hundreds to thousands of "consumers"
> and "producers" most
> will be c++ clients some will be jms clients and in the future when the .net
> will support trunk i will use it as well (that the dream at least)

OK, and what throughput and latency do you need for each client? What
is your average (real world) message size? I take it that this is all
transient pub/sub messaging?

> i dont wont to losse even one message meanning i dont want to create a
> situation where more data is beaing pushed in than is beaing pulled out
> (there might fluxes but over a long time the equilirium will survie - that
> the plan)

Does this mean that your application is latency sensitive?

You mean you are going to throttle your publishers based on the
results of empirical testing? Or are you wanting to throttle
dynamically based on latency numbers experienced by clients?

> while trying to build such a configuration i ofcourse want to achieve a hi
> ratio at least the 300K promissed although i saw papers talking about
> "planned" performence of 500K and 1M per seconds

Who promised 300k? And what is 300k in this context? Where did you see
these numbers?

> i am curently un able to acheive this even with a semi - empty message (
> amessage containing several characters numbering the message)

What is your test doing precisely? I'm afraid I still don't have a
clear understanding of your topology or use case, so it is hard to
give indications of likely performance or tuning guidelines.

RG

Re: Trunk Version - RHMD Vs QPID - And General Performence

[Carl Trieloff <cc...@redhat.com>]

mark yoffe wrote:
> Hi again
>
> in regards to
>
>   
>> Can you expand on this? What are your throughput and latency
>> requirements and how many clients do you need to support? Are your
>> requirements for the Java clients the same as those for the C++
>> clients?
>>     
>
> I want to to create a configuration of hundreds to thousands of "consumers"
> and "producers" most
> will be c++ clients some will be jms clients and in the future when the .net
> will support trunk i will use it as well (that the dream at least)
>
>
> i dont wont to losse even one message meanning i dont want to create a
> situation where more data is beaing pushed in than is beaing pulled out
> (there might fluxes but over a long time the equilirium will survie - that
> the plan)
> in order toachive that i have to understand the "limitations" of a broker
> (the c++ broker specifficly)
> i intened to use multiple computers of course
> and i need to understand whats the coerct ratio betwen Brokker to clients
>
>   

I think RG commented on most of this. I will add one comment.

If you pushing faster than you consume then the broker will have 
increasing queue depth. At some
point you will run out of memory -- to prevent this you can set policies 
to page to disk, however disk
is only prolong the end point where the disk is full. At this point the 
publisher get stopped.

So if you are wanting to do reliable transient messaging, for best 
performance make sure you have enough memory
to handle your expect queue depth.

Use can achieve reliable publish and consume with AMQP 0-10, using the 
correct acquire modes. build perftest in
the cpp/src/tests directory and do a ./perftest --help



> while trying to build such a configuration i ofcourse want to achieve a hi
> ratio at least the 300K promissed although i saw papers talking about
> "planned" performence of 500K and 1M per seconds
> i am curently un able to acheive this even with a semi - empty message (
> amessage containing several characters numbering the message)
>
>
> i hope this explains better the scenario i am trying to create
>
> any thoughts and/or explanations about twiking the box which is running the
> broker for better performence will be apreciated
>   

on RHEL:
turn cpuspeed off
turn irqbalance off
set TSC if your processors supports it
isolate your OS on one core
set irq and IO and CPU affinity
do you have NUMA? -- if so I can provide info for that
set your interrupt affinity
set your socket buffer size = frame size for throughput.
increase the bounds-multiplier when using latest version of trunk for 
throughput

As RG points out, to be more specific we will need to know a few more 
details, however,
that should get you going, enjoy
Carl.

Re: Trunk Version - RHMD Vs QPID - And General Performence

[mark yoffe <ma...@gmail.com>]

Hi again

in regards to

>Can you expand on this? What are your throughput and latency
>requirements and how many clients do you need to support? Are your
>requirements for the Java clients the same as those for the C++
>clients?

I want to to create a configuration of hundreds to thousands of "consumers"
and "producers" most
will be c++ clients some will be jms clients and in the future when the .net
will support trunk i will use it as well (that the dream at least)


i dont wont to losse even one message meanning i dont want to create a
situation where more data is beaing pushed in than is beaing pulled out
(there might fluxes but over a long time the equilirium will survie - that
the plan)
in order toachive that i have to understand the "limitations" of a broker
(the c++ broker specifficly)
i intened to use multiple computers of course
and i need to understand whats the coerct ratio betwen Brokker to clients

while trying to build such a configuration i ofcourse want to achieve a hi
ratio at least the 300K promissed although i saw papers talking about
"planned" performence of 500K and 1M per seconds
i am curently un able to acheive this even with a semi - empty message (
amessage containing several characters numbering the message)


i hope this explains better the scenario i am trying to create

any thoughts and/or explanations about twiking the box which is running the
broker for better performence will be apreciated


Regards

Mark


On 5/17/08, Robert Greig <ro...@gmail.com> wrote:
>
> 2008/5/17 mark yoffe <ma...@gmail.com>:
>
> > i am currentlly trying to build a setup
> > using the qpidd/or rhmd c++ borker and
> > the c++ client ,  i intened to use the java/jms(i think jms) client as
> well
> >
> > if i understand corectlly by your explanations there is no real reason to
> go
> > back to M2.1
> > instead of using trunk
>
> For the java broker and client, the M2.1 codebase has undergone
> significantly more testing. However if you need to use C++ then you
> really need to stick to trunk.
>
> > i would like to achieve hi performence for mesage passing
>
> Can you expand on this? What are your throughput and latency
> requirements and how many clients do you need to support? Are your
> requirements for the Java clients the same as those for the C++
> clients?
>
> RG
>

Re: Trunk Version - RHMD Vs QPID - And General Performence

[Robert Greig <ro...@gmail.com>]

2008/5/17 mark yoffe <ma...@gmail.com>:

> i am currentlly trying to build a setup
> using the qpidd/or rhmd c++ borker and
> the c++ client ,  i intened to use the java/jms(i think jms) client as well
>
> if i understand corectlly by your explanations there is no real reason to go
> back to M2.1
> instead of using trunk

For the java broker and client, the M2.1 codebase has undergone
significantly more testing. However if you need to use C++ then you
really need to stick to trunk.

> i would like to achieve hi performence for mesage passing

Can you expand on this? What are your throughput and latency
requirements and how many clients do you need to support? Are your
requirements for the Java clients the same as those for the C++
clients?

RG

Re: Trunk Version - RHMD Vs QPID - And General Performence

[mark yoffe <ma...@gmail.com>]

Hi thanks for the quick replies and questions

i am currentlly trying to build a setup
using the qpidd/or rhmd c++ borker and
the c++ client ,  i intened to use the java/jms(i think jms) client as well

if i understand corectlly by your explanations there is no real reason to go
back to M2.1
instead of using trunk

i would like to achieve hi performence for mesage passing
it apears that the c++ mesages accept only string objects
and have a message overhead so i do not know how to check the actual
messages size
most my messages have "message data" of less than 500 characters some are a
little bigger

how can i tune the broker for best performence
my current test have not come close to the promissed performence
capabilities of the qpid

please advise me how to achive this tuning

i have tested on a quad core with 4 gigs of memory using centos last
release.

the box will be dedicated to this, so i can tune any part suggested by u


Best Regards
and thanks again

Yoffe Mark




On 5/17/08, Robert Greig <ro...@gmail.com> wrote:
>
> 2008/5/17 mark yoffe <ma...@gmail.com>:
>
> > 2 - Is it problematic to use the trunk version in its current form ?
> > 3 - what is the "future" plan for the trunk version (c++ broker
> specificlly)
> > , when is the Beta, or RC's  planned as i currently see most efforts are
> > directed towords M2.1(maybe M2.2
> >     as M2.1 just released officially )?
>
> Mark, which clients are you planning on using? Are you planning on
> using both C++ clients and broker?
>
> If you could describe what you are trying to do - i.e. your functional
> and non-functional requirements - we could comment on that.
>
> RG
>

Re: Trunk Version - RHMD Vs QPID - And General Performence

[Robert Greig <ro...@gmail.com>]

2008/5/17 mark yoffe <ma...@gmail.com>:

> 2 - Is it problematic to use the trunk version in its current form ?
> 3 - what is the "future" plan for the trunk version (c++ broker specificlly)
> , when is the Beta, or RC's  planned as i currently see most efforts are
> directed towords M2.1(maybe M2.2
>     as M2.1 just released officially )?

Mark, which clients are you planning on using? Are you planning on
using both C++ clients and broker?

If you could describe what you are trying to do - i.e. your functional
and non-functional requirements - we could comment on that.

RG

Re: Trunk Version - RHMD Vs QPID - And General Performence

[Carl Trieloff <cc...@redhat.com>]

mark yoffe wrote:
> Hi
>
> I am currently involwed in a project using rhmd
> as far as i understand from threads posted here
> rhmd is the trunk version of qpid with an extended plugin - used for
> persistency which is based on Berkley DB
> and does not support apache license that is why it is not part of the
> standard destribution
> (please corect me if i am wrong)
>   

mostly,  it does have high speed AIO store, mgnt, console, etc, extras. 
for detailed
info on rhmd it would be better to ask on the 
rhemrg-users-list@redhat.com list.

I will answer any qpidd questions here.

> several questions
>
> 1 - Is there any reason to use the rhmd version does it offer any "extra"
> features/benefits that are not part of qpidd?
>   

see above.

> 2 - Is it problematic to use the trunk version in its current form ?
>   

No issues using trunk, however note that trunk is under active development.


> 3 - what is the "future" plan for the trunk version (c++ broker specificlly)
> , when is the Beta, or RC's  planned as i currently see most efforts are
> directed towords M2.1(maybe M2.2
>      as M2.1 just released officially )?
>   

M2.1 was our last M2.x release, unless we find something that really 
needs to be fixed on M2.x versions. M2.x
is a AMQP 0-8/9 version.

We currently are working to a M3 for trunk. For details on M3 see 
http://cwiki.apache.org/qpid/roadmap.html, which
will be AMQP 0-10 (most of it) and backwards compat to M2.x for some of 
the components. That matrix is on the
wiki. It might be M4 before everything is updated.

> 4 - If i am looking for the promissed Qpidd performence capabilities ( i
> found reports on 300K messages per second ), what version should i use? does
> the version affect performence?
>      and if so how high/low does the trunk score in that field ?
>   

Performance is dependent on what client you use, hardware, OS tuning, 
message size etc. C++ client
being the fastest.  With a well tuned setup you can get why higher perf 
than 300k msg/sec for message sizes
from 64 bytes to 1k.  Larger messages sizes than that, you need 10G to 
get high rates as you will become
bandwidth limited. Re-based versions of trunk is where the most of 
performance testing has been done
for the C++ broker.

yes src rev does affect performance as the trunk perf may go up and down 
based on check-ins, so there
 are revisions that are faster than others, but just about any trunk 
version can perform in the 300k/sec range with
basic tuning using C++ client on a multi core box. I have seem 
throughput runs a lot higher than that.  I can't
however publically disclose my employers benchmark data before they do, 
but I can help you tune your setup if
you are willing to provide some details on it.

kind regards,
Carl.