Performance/usage guidelines?

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Performance/usage guidelines?

JaredM
Hi,

I'm new to message queues and have been searching for some usage guidelines.  I understand that the biggest factors to think about regarding performance seem to be message size and the volume or rate of messages.

However, I want to know what considerations should I think about when deciding on practical limits for the number of queues or topics?

Here is a fictional scenario (and I do mean fictional before someone points me towards XMPP/Jabber): I want to build an Instant Messaging service for 100000 users.  The service would need to accommodate chat rooms as well as instant messaging.  So would I create a queue for each IM and a topic for every chat room?  If so, how many queues or topics could I create before I run into performance problems?  Or is the number of queues and topics all irrelevant and the only important factor is the size and volume of messages?
Reply | Threaded
Open this post in threaded view
|

Re: Performance/usage guidelines?

James Strachan-2
On 12/12/06, JaredM <[hidden email]> wrote:

>
> Hi,
>
> I'm new to message queues and have been searching for some usage guidelines.
> I understand that the biggest factors to think about regarding performance
> seem to be message size and the volume or rate of messages.
>
> However, I want to know what considerations should I think about when
> deciding on practical limits for the number of queues or topics?
>
> Here is a fictional scenario (and I do mean fictional before someone points
> me towards XMPP/Jabber): I want to build an Instant Messaging service for
> 100000 users.  The service would need to accommodate chat rooms as well as
> instant messaging.  So would I create a queue for each IM and a topic for
> every chat room?  If so, how many queues or topics could I create before I
> run into performance problems?  Or is the number of queues and topics all
> irrelevant and the only important factor is the size and volume of messages?

If you want to implement a chat service then you might wanna consider
Jabber. However using ActiveMQ as a chat server is fine too.

I'd use a topic for each chat room and each client should create one
(or more) temporary queues for folks to talk to directly to them.
--

James
-------
http://radio.weblogs.com/0112098/
Reply | Threaded
Open this post in threaded view
|

Re: Performance/usage guidelines?

JaredM
James.Strachan wrote
If you want to implement a chat service then you might wanna consider
Jabber. However using ActiveMQ as a chat server is fine too.

I'd use a topic for each chat room and each client should create one
(or more) temporary queues for folks to talk to directly to them.
Hi James,

Many thanks for the response.  I don't want to really build a chat server, if I did I would definitely use Jabber :).  However, for my example it seemed like an easy one to describe.

What practical limitations should I expect when creating a topic for each chat? Say there are 10,000 (or 100k or 1m?) chat rooms?
Reply | Threaded
Open this post in threaded view
|

Re: Performance/usage guidelines?

James Strachan-2
On 12/12/06, JaredM <[hidden email]> wrote:

> James.Strachan wrote:
> >
> > If you want to implement a chat service then you might wanna consider
> > Jabber. However using ActiveMQ as a chat server is fine too.
> >
> > I'd use a topic for each chat room and each client should create one
> > (or more) temporary queues for folks to talk to directly to them.
> >
>
> Hi James,
>
> Many thanks for the response.  I don't want to really build a chat server,
> if I did I would definitely use Jabber :).  However, for my example it
> seemed like an easy one to describe.
>
> What practical limitations should I expect when creating a topic for each
> chat? Say there are 10,000 (or 100k or 1m?) chat rooms?

You could look at federating chatrooms across different servers (the
forthcoming JEDI transport should help there). But until then the main
overhead of topics is a small amount of RAM in the broker. So assuming
you've plenty of heap in the broker, you should be able to create lots
of topics.

--

James
-------
http://radio.weblogs.com/0112098/
Reply | Threaded
Open this post in threaded view
|

Re: Performance/usage guidelines?

JaredM
Do you know when the JEDI transport will be released and stable for use?

James.Strachan wrote
You could look at federating chatrooms across different servers (the
forthcoming JEDI transport should help there). But until then the main
overhead of topics is a small amount of RAM in the broker. So assuming
you've plenty of heap in the broker, you should be able to create lots
of topics.
Reply | Threaded
Open this post in threaded view
|

Re: Performance/usage guidelines?

James Strachan-2
On 12/13/06, JaredM <[hidden email]> wrote:
>
> Do you know when the JEDI transport will be released and stable for use?

No - we're waiting for John to submit his patch :)

However if you want something now you could tinker with the fanout
transport which does a fair bit of what you need. But hopefully JEDI
will evolve to provide various ways of federating destinations across
different brokers.
--

James
-------
http://radio.weblogs.com/0112098/