Are there any figures about ActiveMQ's scalability

["Ames, Andreas (Andreas)" <am...@avaya.com>]

Hi all,

I'm in the process of evaluating ActiveMQ in a callcenter setting.
I'm unable to find figures about its scalability.

In my scenario I'll have a typical middletier server 'connected' 
to a diversity of frontend clients via ActiveMQ.  That will mean 
about 6000 pub/sub-channels for event delivery with at most two or 
three producers and a varying number of consumers.  Unfortunately 
I'll also have to provide some request/response-support.  I've 
read the recommendation to use temporary queues to deliver the 
responses.  As I might need to support (in the worst case) up to 
500 clients, I'm concerned about scalability (500 queues 
additionally).

I'm only talking about non-persistent messages for the moment.  

I'm not yet decided about duplicate acks at the moment, I'll need to 
read a bit more and do some experimentation.

I'm expecting a maximum of about 12-15 messages per second at the 
moment.

I'm currently planning for a single (TCP-) connection per client 
(=> max. 500).

So out of your experience, would you say that a single broker can 
'easily' stand this load or should I I plan with a broker network 
right from the beginning?


TIA,

aa

--
Andreas Ames | Programmer | Comergo GmbH | ames AT avaya DOT com

Sitz der Gesellschaft: Stuttgart
Registergericht: Amtsgericht Stuttgart - HRB 22107
Geschäftsführer: Andreas von Meyer zu Knonow, Udo Bühler, Thomas Kreikemeier
 

Re: Are there any figures about ActiveMQ's scalability

[Greg Griffin <na...@griffinhome.net>]

I can give you an example from my experience. On a Windows XP, 3.0Ghz dual
core, 2GB RAM, with 4.1.1 java, and 2.0.1 CMS (C++ client)
    average 100 msg/sec with 1,000 topics. 3-4 producers with 6-7 consumers,
use no more than 2% of Cpu on the broker, and maybe 1% on each consumer or
producer. I've profiled the apps, and the publish and receive take up about
50% of the CPU time, so most of the timing above has to do with ActiveMQ,
not anything specific to my app. 

I've been able to get about 5,000 msg/sec max on topics using one consumer
and one producer using all java, with 4 fields in a BytesMessage.

Have not dealt with queues.

Given the above, it would seem you would be fine with one broker, but
depends on the specs of your machine.

You can modify the example code quickly to get numbers more specific to your
setup.

Note that I do see some memory leak on the broker, mentioned in a forum
message just after yours:
http://www.nabble.com/broker-memory-leak-with-many-topics-tf3845795s2354.html
You can also see the example code in this message, to see how to deal with
multiple topics, and to reproduce the numbers mentioned above.

-- 
View this message in context: http://www.nabble.com/Are-there-any-figures-about-ActiveMQ%27s-scalability-tf3835059s2354.html#a10945043
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: Are there any figures about ActiveMQ's scalability

[James Strachan <ja...@gmail.com>]

On 5/29/07, Ames, Andreas (Andreas) <am...@avaya.com> wrote:
> Hi all,
>
> I'm in the process of evaluating ActiveMQ in a callcenter setting.
> I'm unable to find figures about its scalability.
>
> In my scenario I'll have a typical middletier server 'connected'
> to a diversity of frontend clients via ActiveMQ.  That will mean
> about 6000 pub/sub-channels for event delivery with at most two or
> three producers and a varying number of consumers.  Unfortunately
> I'll also have to provide some request/response-support.  I've
> read the recommendation to use temporary queues to deliver the
> responses.  As I might need to support (in the worst case) up to
> 500 clients, I'm concerned about scalability (500 queues
> additionally).

The number of destinations doesn't really matter; its really just a
RAM overhead in the broker; a small amount of RAM is used for each
destination.

Whats more relevant is how many connections the broker has to maintain
(as a socket & thread is usually used per connection) and some OSes
have a limit of the maximum sockets/threads per process (which you can
often increase). e.g. on a small linux box I've tested 2000
connections on a single broker which works fine.

Also message throughput is something to consider; but usually a single
broker can deal with most common loading requirements


> I'm only talking about non-persistent messages for the moment.
>
> I'm not yet decided about duplicate acks at the moment, I'll need to
> read a bit more and do some experimentation.
>
> I'm expecting a maximum of about 12-15 messages per second at the
> moment.

Thats pretty low; so a single oldish PC should do the trick for the broker


> I'm currently planning for a single (TCP-) connection per client
> (=> max. 500).
>
> So out of your experience, would you say that a single broker can
> 'easily' stand this load or should I I plan with a broker network
> right from the beginning?

I'd say a single broker could easily handle double those numbers of
connections and 10x the message throughputs - on a cheap/old PC. On a
nice newish blade you might be able to add another zero to those
figures

-- 
James
-------
http://macstrac.blogspot.com/