activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sean Bastille" <sean.basti...@gmail.com>
Subject Re: Confusing results for my performance testing
Date Thu, 21 Feb 2008 23:33:50 GMT
Was this all running on a single 6-cpu host?

I found your initial results surprising given that I have done similar
testing just a few weeks ago that struggled to make a third of your
throughput, but my tests involved two 2-cpu hosts, so this likely accounts
for the difference.

Also to clarify, when you say 10 consumers processed 5820/s, are you
referring to the total throughput as being 5820, or each consumer handling
5820, for a total of 58k/s?

Assuming the former, I believe you are experiencing the same limitations I
was running into, which is the consumer being CPU bound.  You should be able
to investigate further using top or sar.

My peak throughput configuration involved 3 producers and 2 consumers,
although this was with each process running its own embedded broker.

Sean

On Thu, Feb 21, 2008 at 6:03 PM, zaoliu <zaoliu@gmail.com> wrote:

>
> An issue when testing performance s when I increase the number of
> consumers
> for testing non-persistent messages, the throughput get down very fast. I
> can't find the reason for it. Each consumer thread is a separate
> connection
> to the broker.
> Below is my result for testing (all using one producer to send messages in
> a
> separate JVM):
> 1 consumer:               12683/s
> 2 consumers:              11289/s
> 3 consumers:               9956/s
> 4 consumers:               8638/s
> 10 consumers:             5820/s
>
> To my understanding, increasing the consumer numbers should improve the
> throughput of brokers, but the result is opposite to my expectation.
>
> Zao
> --
> View this message in context:
> http://www.nabble.com/Confusing-results-for-my-performance-testing-tp15622219s2354p15622219.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>
>

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