activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevin Burton <bur...@spinn3r.com>
Subject Re: Lots of small ActiveMQ instances or one big one?
Date Fri, 13 Mar 2015 21:04:17 GMT
I’m getting mixed messages :-P

This statement:

To drive the disk, the more parallel work that the brokers can
> introduce the better. In other words, to get max throughput, you can
> increase the num of parallel jms connections per destination, the the
> number of destinations per broker, then the number of brokers. At each
> stage track peek throughput till it starts to drop off before
> introducing the next level of parallelism.


conflicts with this one:

Increasing the number of producers and destinations involved will increase the
> disk utilization.


Unless I’m missing something.

I have some tests that show that the more workers the better throughput.


On Fri, Mar 13, 2015 at 1:30 PM, artnaseef <art@artnaseef.com> wrote:

> Exactly where my thoughts were going.   The usage of destinations will
> have a
> big impact here.  If there is one producer to a single queue with
> persistent
> messages, the bottleneck is going to be the message acknowledgements which
> require the "sync" to disk.
>
> Increasing the number of producers and destinations involved will increase
> the disk utilization.
>
> Syncs are hard to see in the scheme of things since they involve waits at
> several points and don't show up as significant CPU usage, disk usage, etc.
> In other words, it can be hard to see that syncs are the bottleneck.
>
>
>
> --
> View this message in context:
> http://activemq.2283324.n4.nabble.com/Lots-of-small-ActiveMQ-instances-or-one-big-one-tp4693133p4693192.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>



-- 

Founder/CEO Spinn3r.com
Location: *San Francisco, CA*
blog: http://burtonator.wordpress.com
… or check out my Google+ profile
<https://plus.google.com/102718274791889610666/posts>
<http://spinn3r.com>

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