Large amounts of queues and topics

[ripienaar <ri...@devco.net>]

I am working on a system that has large amounts of topics often connected in
a network of brokers.  Clients are mostly using the Stomp protocol.  I am
now looking at also adding potentially a lot of queues and was seeking some
design advice on scalability.

For me the most important characteristic is that message latency should be
low even for 1000s of subscribes, this works well today with just topics and
subscribers subscribing to a topic of messages they want.

I am concerned that adding a lot - 1000s - of queues would impact
performance a lot due to the typical 1 thread per queue, topic and
subscriber (I know these are tunable and I can use NIO).

I can now redesign things so that instead of many many topics and queues I
use headers and JMS selectors when subscribing and publishing, this way I
can have only a hand full of queues and topics with subscribers maintaining
many subscriptions on these queues/topics.

It's not clear which of these two strategies will work best in the long run
and so was wondering what would be the most resource intensive on the broker
and the network of brokers wrt to threads, cpu, memory etc. and what would
be the best practice for this kind of application keeping in mind message
latency is very important.

Thanks

--
View this message in context: http://activemq.2283324.n4.nabble.com/Large-amounts-of-queues-and-topics-tp3471410p3471410.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: Large amounts of queues and topics

[Gary Tully <ga...@gmail.com>]

the selectors are run on the broker, but on only on the in-memory part
of the queue. For this reason, if you have sparse selectors, you need
to configure a large page size for the destination such that most of
the pending messages can be in memory.

The pageSize defaults to 200 and is configured via a destination
policyEntry.maxPageSize, make that 2000 (or larger than the selector
span) and you will get all of the required messages.

On 26 April 2011 15:41, goku <fa...@gmail.com> wrote:
> Hi,
>
> I'm interested in similar scenario as well. Any advice would be appreciated.
>
> Could someone please confirm if I'm right or wrong on this. It seems  to me
> that "selector" operation is done within MessageConsumer implementation.
> (i.e. ALL messages are still dispatched from Message Broker to
> MessageConsumer and then "selector" operation are performed against those
> messages).  The problem occurs when we have a bunch of messages that we are
> not interested in (i.e. not match our selector), those messages will
> eventually fill up MessageConsumer's internal queue due to prefetch or cache
> limit. As a result, we will not be able to receive any new messages,
> particularly the ones we're interested in with the selector.
>
> So, is there a way to configure AMQ to perform the selector operation on
> MessageBroker side? Should I start looking at "interceptor" and create my
> own BrokerPlugin? Any advice on how to workaround this issue?
>
> I'm really appreciate any answer.
>
> Soonthorn A.
>
> --
> View this message in context: http://activemq.2283324.n4.nabble.com/Large-amounts-of-queues-and-topics-tp3471410p3475617.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>



-- 
http://blog.garytully.com
http://fusesource.com

Re: Large amounts of queues and topics

[goku <fa...@gmail.com>]

Hi,

I'm interested in similar scenario as well. Any advice would be appreciated.

Could someone please confirm if I'm right or wrong on this. It seems  to me
that "selector" operation is done within MessageConsumer implementation. 
(i.e. ALL messages are still dispatched from Message Broker to
MessageConsumer and then "selector" operation are performed against those
messages).  The problem occurs when we have a bunch of messages that we are
not interested in (i.e. not match our selector), those messages will
eventually fill up MessageConsumer's internal queue due to prefetch or cache
limit. As a result, we will not be able to receive any new messages,
particularly the ones we're interested in with the selector. 

So, is there a way to configure AMQ to perform the selector operation on
MessageBroker side? Should I start looking at "interceptor" and create my
own BrokerPlugin? Any advice on how to workaround this issue?

I'm really appreciate any answer.

Soonthorn A.

--
View this message in context: http://activemq.2283324.n4.nabble.com/Large-amounts-of-queues-and-topics-tp3471410p3475617.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: Large amounts of queues and topics

[Bruce Snyder <br...@gmail.com>]

On Sun, Apr 24, 2011 at 6:58 AM, ripienaar <ri...@devco.net> wrote:
> I am working on a system that has large amounts of topics often connected in
> a network of brokers.  Clients are mostly using the Stomp protocol.  I am
> now looking at also adding potentially a lot of queues and was seeking some
> design advice on scalability.
>
> For me the most important characteristic is that message latency should be
> low even for 1000s of subscribes, this works well today with just topics and
> subscribers subscribing to a topic of messages they want.
>
> I am concerned that adding a lot - 1000s - of queues would impact
> performance a lot due to the typical 1 thread per queue, topic and
> subscriber (I know these are tunable and I can use NIO).
>
> I can now redesign things so that instead of many many topics and queues I
> use headers and JMS selectors when subscribing and publishing, this way I
> can have only a hand full of queues and topics with subscribers maintaining
> many subscriptions on these queues/topics.
>
> It's not clear which of these two strategies will work best in the long run
> and so was wondering what would be the most resource intensive on the broker
> and the network of brokers wrt to threads, cpu, memory etc. and what would
> be the best practice for this kind of application keeping in mind message
> latency is very important.

I'm assuming that you have read the following page on the ActiveMQ website:

http://activemq.apache.org/how-do-i-configure-10s-of-1000s-of-queues-in-a-single-broker-.html

Instead of thousands of destinations or thousands of JMS selectors, my
experience has taught me that a mix of the two is the best approach
(especially in a situation where you have thousands of JMS clients
connecting to the network of brokers). Although you can tune ActiveMQ
to handle it, thousands of destinations tend to tax the broker
unnecessarily, especially if you can send messages on the same
destination and partition those messages using JMS selectors and/or
message groups. But remember that selectors must be applied to every
message that flows through the broker, so there is a tipping point for
them as well. I have achieved the best results by dividing messages
across a smaller number of destinations using a smaller number of
selectors. Finding the appropriate balance requires experimentation in
your environment with lifelike load testing.

Bruce
-- 
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'

ActiveMQ in Action: http://bit.ly/2je6cQ
Blog: http://bruceblog.org/
Twitter: http://twitter.com/brucesnyder