activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevin Burton <bur...@spinn3r.com>
Subject Re: Performance single vs. multiple queues / sessions / consumers
Date Thu, 21 May 2015 23:54:59 GMT
The current version of ActiveMQ doesn’t really scale well over say
1000-2000 queues (if you GC them).

If you create one queue per client then you will have lots of queues.

I haven’t submitted my patches yet (trying to port our code to 5.11) but it
should resolve that situation.

On Thu, May 21, 2015 at 8:42 AM, Klaus Liebler <k.liebler@kon-cept.de>
wrote:

> Dear list members,
>
> I am trying to understand the performance profile of ActiveMQ. Let's
> assume, we have some 500 clients sending the same type of messages (status
> updates) to one single central server - basically a windows service that
> interacts with a SQL database on the same machine. Which of the following
> configurations would you recommended (N= Number of clients)?
>
> -          Give each client its own upload queue -> N queues. Listen with
> one session. Create one consumer in this session (destination with
> wirdcards) that processes all messages.
>
> -          Give each client its own upload queue -> N queues. Listen with
> one session. Create N consumers in that session (one for each queue)
>
> -          Give each client its own upload queue -> N queues. Listen with
> N sessions (one for each queue)
>
> -          Use one single upload queue used by all clients. Listen with
> one/N session(s) each having one/N consumers.
>
> In other words: How does the number of queues affect the ability to
> parallelize processing?
>
> Maybe you can point me to the information that explains the relevant
> relationships...
>
> Your advice is greatly appreciated!
>
> Thanks a lot for your help!
>
> Klaus
>



-- 

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>

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