RabbitMQ - Channel Pooling - Number of Channels per connection

[getaju69]

In the RabbitMQ documentation, I see:

Given both of these factors, limiting the number of channels used per connection is highly recommended. As a rule of thumb, most applications can use a single digit number of channels per connection. Those with particularly high concurrency rates (usually such applications are consumers) can start with one channel per thread/process/coroutine and switch to channel pooling when metrics suggest that the original model is no longer sustainable, e.g. because it consumes too much memory. 

We were using one channel for multiple threads. We have changed our architecture now to use a channel pool. and each thread would get its own channel (from the pool)

But we do see that our current setting ( max size of 5 for the pool)  is not enough and we would like to increase it further. But we are wary of doing this, since the documentation shows it should be a single digit number.

Is that statement in the documentation still relevant and should we go for a different approach?

[Luke Bakken]

Hello,

Please provide information about which client library you are using and its version. It would be great to know which RabbitMQ version you are using too.

Thanks,

Luke

[getaju69]

amqp client version: 5.9.0  

rabbitmq server 3.8.0 Erlang 22.1.5  

[getaju69]

Also note that this particular problem\question is related to publishing of messages using the channel to the exchange.

[Luke Bakken]

Hello,

My suggestion is to make your changes and run benchmarks. I'll make sure the Java client maintainer sees your question as well

Thanks,

Luke

[Arnaud Cogoluègnes]

A few dozens channels is reasonable (the default maximum is 1023 or 2047 IIRC), the documentation covers the most common cases we see in the wild. There's some synchronization going on at the socket level to avoid frame interleaving, but that should not affect throughput much in this range (I'm speaking about the Java client here). As Luke suggested, you should experiment with your target workload and see what comes out of it. Again, you're still in the reasonable range of channels per connection so far.