Best practices regarding multiple queues/consumers/threads

[justinmiller]

I'm trying to figure out what the best practice is for setting up listeners, queues, consumers, etc. Here's my scenario:

In recent releases of spring-amqp, you can pass in an array of queueNames to a SimpleMessageListenerContainer. Let's say you pass in 3 queues, and you have set the number of concurrentConsumers to 10. By default, you'll get a thread pool handling your consumers equal to the number of concurrentConsumers.

So in this scenario, you'll have 10 threads where 1 channel is created per thread, each of which is consuming from 3 queues. In other words, you'll end up with 10 consumers per queue (30 consumers total), being processed by 10 threads. Sorry if that was unnecessarily complicated.

Anyhoo, I guess my question is, is that optimal and the most performant? Is it better to have 1 thread/channel for each consumer of each queue, i.e. 30 threads and channels? Should I have fewer threads?

One thing I've noticed is that while profiling with this configuration, there are periods of time when I definitely have messages queued (as shown by rabbitmqctl), but a number of my listener threads are just hanging out waiting for messages to be delivered (they're parked). I would like them to be more busy if there are messages available.

Thanks,
Justin

[Dave Syer]

The number of threads should be governed purely by your ability to process messages, so there is no magic number for that (hence it is configurable). I guess I'm interested to hear more about the hanging out consumers. Certainly it might be the case that having 3 consumers on each channel could slow them down, because they are not going to consume concurrently. There is also only one connection thread as far as I know, so that might end up being a bottleneck - there is a JIRA ticket (AMQP-77) for extending CachingConnectionFactory to use one Connection per Channel instead of one Connection (and I know that will improve throughput).