Hi,

I am thinking about the RabbitMQ topology for my new API. Each API
call has an API key, and can be one of three calls. I'll have the
three controllers parse / validate the arguments, and then enqueue the
tasks in RabbitMQ. I will then have a service that consumes this
queue(s), and process each of the tasks.

Each API calls will take different times to process.

The question is, should I have

1. One queue where all API calls are fed into (1 queue)
2. One queue per API call (3 queues)
3. One queue per API key (N queueswhere N is the number of customers)
4. One queue per APi key / API operations (3*N queues)

Is there a performance advantage to dequeuing from multiple queues
versus just one? I know that each queue has around 4kb of extra
information with it, so we don't want to make too many. Is there any
sort of locking disadvantage to just having one queue with a lot of
traffic?

Thanks for your help!

Search Discussions

  • Simon MacMullen at Oct 27, 2011 at 10:36 am

    On 27/10/11 05:40, Ilya Volodarsky wrote:
    Is there a performance advantage to dequeuing from multiple queues
    versus just one? I know that each queue has around 4kb of extra
    information with it, so we don't want to make too many. Is there any
    sort of locking disadvantage to just having one queue with a lot of
    traffic?
    Well, each queue needs to maintain ordering for the messages that pass
    through it, so each queue is a single process. If you have a machine
    with lots of cores, or a cluster, you can get more performance out of
    several queues than a single one. The overhead per queue is not huge.

    Cheers, Simon

    --
    Simon MacMullen
    RabbitMQ, VMware

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouprabbitmq-discuss @
categoriesrabbitmq
postedOct 27, '11 at 4:40a
activeOct 27, '11 at 10:36a
posts2
users2
websiterabbitmq.com
irc#rabbitmq

People

Translate

site design / logo © 2021 Grokbase