1

In project written in Erlang what are the best practices organizing connections to RabbitMQ? I have a big number of long living Erlang processes, each of them needs to send/receive messages through RabbitMQ. Shall I open connection in all of them or fix-sized pool is better? Is there already a library for that task? Maybe it's better to share even a channel?

Eugene Shubin
  • 23
  • 3

1 Answers1

0

One connection per process.

Use multiple channels within that connection. Generally speaking, 1 channel per message producer or consumer is a good place to start.

The important part, though, is that you only have 1 connection per process.

Derick Bailey
  • 72,004
  • 22
  • 206
  • 219
  • Just found an opposite statement http://stackoverflow.com/questions/10407760/is-there-a-performance-difference-between-pooling-connections-or-channels-in-rab – Eugene Shubin Sep 09 '15 at 11:26
  • that post confirms what i said about connections. it suggests a different approach to channels, which is fine. how you use channels is up to you. they are cheap. in my experience, though, keeping channels dedicated to only publishing or to only consuming from a specific queue makes it easier. – Derick Bailey Sep 09 '15 at 12:11
  • Derick, you offer one connection per process, and I have a lot of processes. Let's say process per HTTP connection. Do you think it's still a good idea to open amqp connection for each of them? – Eugene Shubin Sep 09 '15 at 13:38
  • i'm wondering if we are using different definition of "process". your web app is 1 running programming... each web app instance is 1 running process that needs to connect to rabbitmq. there should be 1 rabbitmq connection for each application instance that needs to connect to rabbitmq – Derick Bailey Sep 09 '15 at 14:08
  • but back to your original question - if you have 1,000 erlang application instances, and each of them needs to communicate with rabbitmq, then you will probably have 1,000 rabbitmq connections. the only time i would say not to do that, is if the erlang app instances are very short lived - stand up, do work, shut down fast. in that case, communicating to a central process that connects to rabbitmq would be better – Derick Bailey Sep 09 '15 at 14:10
  • I mean Erlang processes on a single node by "processes". – Eugene Shubin Sep 09 '15 at 14:16