You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by bhusted <bh...@yahoo.com> on 2006/07/11 16:56:38 UTC
Load Balancing Pull Model
I am attempting to architect a solution that will require a high degree of
scalability. We need a configuration that can scale a small pool of Brokers
performing light weight processing and in-turn delgate to a compute farm for
intense computational processing. The compute farm will need to pull
requests from the brokers to maximize utilization of spare capacity. A
round robin push model will not suffice.
The client-server model seems to be a good fit where the consumers can load
balance pulling messages across brokers. Any guidance or advice to
implement a pull model strategy would be very much appreciated.
Thanks -
Brian
--
View this message in context: http://www.nabble.com/Load-Balancing-Pull-Model-tf1924982.html#a5271068
Sent from the ActiveMQ - User forum at Nabble.com.
Re: Load Balancing Pull Model
Posted by Hiram Chirino <hi...@hiramchirino.com>.
On 7/11/06, bhusted <bh...@yahoo.com> wrote:
>
>
> >>Depending on hardware and exact OS/JVM/ActiveMQ configuration a single
> broker can handle 10->>100 million messages per hour - so 50 million
> transactions in 24 hours sounds well within the bounds >>of a single
> broker.
>
> Sounds good. What message size has that been tested with?
>
> It sounds like designing for a single message broker what you would
> recommend, but what happens if that becomes a bottleneck?
>
> We are definitely looking at integrating with JBoss and using MDBs for
> this
> implementation. I really like the prefetch option...that can really help
> us
> with the load balancing. I was worried about messages piling up in
> consumer
> queues within the farm.
if the prefetch option is set to 1 then only the 1 message that is currently
being processed by the consumer can pile up.
But, if you can afford to pile a few more messages on a consumer queue then
your consumer will never have to 'wait' for the next message since it will
always be available. This is definitely an option that needs to be tuned
for each app.
--
> View this message in context:
> http://www.nabble.com/Load-Balancing-Pull-Model-tf1924982.html#a5273101
> Sent from the ActiveMQ - User forum at Nabble.com.
>
>
--
Regards,
Hiram
Blog: http://hiramchirino.com
Re: Load Balancing Pull Model
Posted by James Strachan <ja...@gmail.com>.
On 7/11/06, bhusted <bh...@yahoo.com> wrote:
> >>Depending on hardware and exact OS/JVM/ActiveMQ configuration a single
> broker can handle 10->>100 million messages per hour - so 50 million
> transactions in 24 hours sounds well within the bounds >>of a single broker.
>
> Sounds good. What message size has that been tested with?
We tend to test up to a few hundred K per message. For large messages
(in the Gb) we recommend JMS streams...
http://incubator.apache.org/activemq/jms-streams.html
> It sounds like designing for a single message broker what you would
> recommend, but what happens if that becomes a bottleneck?
I'd say start off with one broker and see how you get on; switching
from 1 to many brokers is on the client side a trivial URI change.
Clients automatically load balance across all the brokers they can
find (using static URL configurations or dynamic discovery)
> We are definitely looking at integrating with JBoss and using MDBs for this
> implementation. I really like the prefetch option...that can really help us
> with the load balancing. I was worried about messages piling up in consumer
> queues within the farm.
Agreed - its a very useful feature.
If you are building any kind of compute farm, make sure you check out
Message Groups which provide a very elegant way to partition your data
for efficient concurrency and caching etc...
http://incubator.apache.org/activemq/message-groups.html
--
James
-------
http://radio.weblogs.com/0112098/
Re: Load Balancing Pull Model
Posted by bhusted <bh...@yahoo.com>.
>>Depending on hardware and exact OS/JVM/ActiveMQ configuration a single
broker can handle 10->>100 million messages per hour - so 50 million
transactions in 24 hours sounds well within the bounds >>of a single broker.
Sounds good. What message size has that been tested with?
It sounds like designing for a single message broker what you would
recommend, but what happens if that becomes a bottleneck?
We are definitely looking at integrating with JBoss and using MDBs for this
implementation. I really like the prefetch option...that can really help us
with the load balancing. I was worried about messages piling up in consumer
queues within the farm.
--
View this message in context: http://www.nabble.com/Load-Balancing-Pull-Model-tf1924982.html#a5273101
Sent from the ActiveMQ - User forum at Nabble.com.
Re: Load Balancing Pull Model
Posted by James Strachan <ja...@gmail.com>.
On 7/11/06, James Strachan <ja...@gmail.com> wrote:
> On 7/11/06, bhusted <bh...@yahoo.com> wrote:
> >
> > Thanks for the quick reply.
> >
> > >Do you expect there to be a large numbers of messages; or do you expect
> > there to be a relatively >small number of messages?
> >
> > The requirements are to prepare a solution that can scale to 50 million
> > transactions in a 24 hour period.
>
> Depending on hardware and exact OS/JVM/ActiveMQ configuration a single
> broker can handle 10-100 million messages per hour - so 50 million
> transactions in 24 hours sounds well within the bounds of a single
> broker.
>
> > A transaction will spawn multiple
> > messages on the broker to handle workflow, auditing and a single
> > request/reply to the compute farm. The compute farm will also host a
> > broker for messaging among local components.
> >
> > >What kind of message throughput do you expect? It could be just a single
> > broker would do the trick
> > >(with maybe another broker acting as standby) - or just having 2
> > independent brokers with producers >and consumers connecting to either
> > broker.
> >
> > I think we will definitely need multiple brokers. I would prefer that the
> > consumers have the ability to load balance across brokers - is this
> > possible? What configuration would you recommend?
>
> The simplest solution is to create consumers in each JVM on each
> broker available & share a thread pool across the consumers; so
> however many brokers you run you can easily process messages on the
> consumers. (Using networks for store and forward is less efficient as
> you end up with multi-hops - its easier to just create pools of
> consumers on each broker in a single JVM).
It would be nice to wrap up the above behaviour into a new transport
layer (like peer and failover etc).
I've raised a JIRA...
http://issues.apache.org/activemq/browse/AMQ-816
the benefit of this approach is it allows individual brokers to be
deployed and used in a linear fashion; there's no need to store/foward
between brokers.
--
James
-------
http://radio.weblogs.com/0112098/
Re: Load Balancing Pull Model
Posted by James Strachan <ja...@gmail.com>.
On 7/11/06, bhusted <bh...@yahoo.com> wrote:
>
> Thanks for the quick reply.
>
> >Do you expect there to be a large numbers of messages; or do you expect
> there to be a relatively >small number of messages?
>
> The requirements are to prepare a solution that can scale to 50 million
> transactions in a 24 hour period.
Depending on hardware and exact OS/JVM/ActiveMQ configuration a single
broker can handle 10-100 million messages per hour - so 50 million
transactions in 24 hours sounds well within the bounds of a single
broker.
> A transaction will spawn multiple
> messages on the broker to handle workflow, auditing and a single
> request/reply to the compute farm. The compute farm will also host a
> broker for messaging among local components.
>
> >What kind of message throughput do you expect? It could be just a single
> broker would do the trick
> >(with maybe another broker acting as standby) - or just having 2
> independent brokers with producers >and consumers connecting to either
> broker.
>
> I think we will definitely need multiple brokers. I would prefer that the
> consumers have the ability to load balance across brokers - is this
> possible? What configuration would you recommend?
The simplest solution is to create consumers in each JVM on each
broker available & share a thread pool across the consumers; so
however many brokers you run you can easily process messages on the
consumers. (Using networks for store and forward is less efficient as
you end up with multi-hops - its easier to just create pools of
consumers on each broker in a single JVM).
For help on creating pools of consumers on multiple brokers try jencks...
http://jencks.codehaus.org
or try using MDBs etc
--
James
-------
http://radio.weblogs.com/0112098/
Re: Load Balancing Pull Model
Posted by bhusted <bh...@yahoo.com>.
Thanks for the quick reply.
>Do you expect there to be a large numbers of messages; or do you expect
there to be a relatively >small number of messages?
The requirements are to prepare a solution that can scale to 50 million
transactions in a 24 hour period. A transaction will spawn multiple
messages on the broker to handle workflow, auditing and a single
request/reply to the compute farm. The compute farm will also host a
broker for messaging among local components.
>What kind of message throughput do you expect? It could be just a single
broker would do the trick
>(with maybe another broker acting as standby) - or just having 2
independent brokers with producers >and consumers connecting to either
broker.
I think we will definitely need multiple brokers. I would prefer that the
consumers have the ability to load balance across brokers - is this
possible? What configuration would you recommend?
--
View this message in context: http://www.nabble.com/Load-Balancing-Pull-Model-tf1924982.html#a5272424
Sent from the ActiveMQ - User forum at Nabble.com.
Re: Load Balancing Pull Model
Posted by James Strachan <ja...@gmail.com>.
On 7/11/06, bhusted <bh...@yahoo.com> wrote:
> I am attempting to architect a solution that will require a high degree of
> scalability. We need a configuration that can scale a small pool of Brokers
> performing light weight processing and in-turn delgate to a compute farm for
> intense computational processing. The compute farm will need to pull
> requests from the brokers to maximize utilization of spare capacity. A
> round robin push model will not suffice.
Do you expect there to be a large numbers of messages; or do you
expect there to be a relatively small number of messages?
The out of the box settings work fine for large numbers of messages.
For small amounts of messages (where you want to trade performance for
extra fairness) then reduce the prefetch size to 1
http://incubator.apache.org/activemq/what-is-the-prefetch-limit-for.html
What kind of message throughput do you expect? It could be just a
single broker would do the trick (with maybe another broker acting as
standby) - or just having 2 independent brokers with producers and
consumers connecting to either broker.
--
James
-------
http://radio.weblogs.com/0112098/
Re: Load Balancing Pull Model
Posted by Hiram Chirino <hi...@hiramchirino.com>.
Hi. Yep this has come up before.
Usually folks configure a prefetch of 1 and that seems to satisfy the need.
Do you have a case where this will not work?
Regards,
Hiram
On 7/11/06, bhusted <bh...@yahoo.com> wrote:
>
>
> I am attempting to architect a solution that will require a high degree of
> scalability. We need a configuration that can scale a small pool of
> Brokers
> performing light weight processing and in-turn delgate to a compute farm
> for
> intense computational processing. The compute farm will need to pull
> requests from the brokers to maximize utilization of spare capacity. A
> round robin push model will not suffice.
>
> The client-server model seems to be a good fit where the consumers can
> load
> balance pulling messages across brokers. Any guidance or advice to
> implement a pull model strategy would be very much appreciated.
>
> Thanks -
> Brian
> --
> View this message in context:
> http://www.nabble.com/Load-Balancing-Pull-Model-tf1924982.html#a5271068
> Sent from the ActiveMQ - User forum at Nabble.com.
>
>
--
Regards,
Hiram
Blog: http://hiramchirino.com