qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carl Trieloff <cctriel...@redhat.com>
Subject Re: Trunk Version - RHMD Vs QPID - And General Performence
Date Mon, 19 May 2008 01:29:07 GMT
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.



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