[rabbitmq-discuss] connection/channel pooling
matthew at lshift.net
Wed Nov 11 11:49:33 GMT 2009
On Wed, Nov 11, 2009 at 12:53:25AM +0000, Gojko Adzic wrote:
> a connection can be cached and shared but channels should be
> thread-local. For the purpose of improving throughput, does it make
> sense to create a pool of channels or is there no penalty in opening and
> closing channel for every message sent?
Opening a channel takes some client side and server side resources. If
you are able to use a pool of channels and reuse them then yes, that
would be a better solution to creating endless fresh channels.
> Also, does multi-threaded
> posting through channels belonging to a single connection cause
> contention on the same socket? What's the best practice for throughput -
> should I have a number of connections open to post messages and then
> allocate several channels per connection, or is this an overkill?
There will be contention - at the end of the day, the kernel must
serialise writes to the socket. One can certainly over supply the kernel
with data to write from a single thread, let alone several threads. I
would suggest that you start with the simple thing - use one connection
- and see if that's enough for you. Don't forget premature optimization
is the root of all evil!
With something like Rabbit, it's so flexible and can be configured in
so many different ways that we can't really write extensive "best
practises" because with just a few small differences in the setup, they
may very well cease to be "best". Thus we would always recommend that
you test and benchmark yourself and then make decisions based on what
you see is happening for you.
More information about the rabbitmq-discuss