Есть ли разница в производительности между объединением соединений или каналов в rabbitmq?

Я новичок с Rabbitmq (и программированием), поэтому извините заранее, если это очевидно. Я создаю пул для обмена между потоками, которые работают в очереди, но я не уверен, следует ли использовать соединения или каналы в пуле.

Я знаю, что мне нужны каналы для выполнения фактической работы, но есть ли преимущество в производительности для одного канала на соединение (с точки зрения большей пропускной способности из очереди)? или мне лучше использовать только одно соединение для каждого приложения и объединить множество каналов?

Заметьте: потому что я объединяю ресурсы, первоначальная стоимость не является фактором, поскольку я знаю, что соединения более дороги, чем каналы. Меня больше интересует пропускная способность.

Ответ 1

Я нашел это на веб-сайте rabbitmq, он находится внизу, поэтому я процитировал соответствующую часть ниже.

Версия tl; dr заключается в том, что у вас должно быть 1 соединение для каждого приложения и 1 канал на поток. Надеюсь, что это поможет.

Соединения

Соединения AMQP обычно долговечны. AMQP - приложение который использует TCP для надежной доставки. Соединения AMQP использовать аутентификацию и может быть защищена с использованием протокола TLS (SSL). Когда приложение больше не нужно подключать к брокеру AMQP, оно должен изящно закрыть соединение AMQP, а не резко закрывая базовое TCP-соединение.

Каналы

Некоторым приложениям требуется несколько подключений к брокеру AMQP. Однако нежелательно, чтобы многие TCP-соединения открывались на то же время, потому что это расходует системные ресурсы и делает это больше сложно настроить брандмауэры. Соединения AMQP 0-9-1 - это мультиплексированные с каналами, которые можно рассматривать как "легкие соединения, которые используют одно TCP-соединение".

Для приложений, которые используют несколько потоков/процессов для обработки, очень часто открывается новый канал для потока/процесса, а не разделяйте каналы между ними.

Связь на определенном канале полностью отделена от связь на другом канале, поэтому каждый метод AMQP также содержит номер канала, который клиенты используют, чтобы выяснить, какой канал метод предназначен для (и, следовательно, какой обработчик события должен быть вызван, например).

Рекомендуется, чтобы в потоке было 1 канал, хотя они потокобезопасны, поэтому у вас может быть несколько потоков, отправляемых по одному каналу. Что касается вашего приложения, я бы предположил, что вы придерживаетесь 1 канала на поток, хотя.

Кроме того, рекомендуется иметь только 1 потребитель на канал.

Это только рекомендации, поэтому вам нужно будет провести некоторое тестирование, чтобы увидеть, что лучше всего подходит для вас.

В этом потоке есть некоторые идеи здесь и здесь.

Несмотря на все эти рекомендации этот пост, предположим, что это скорее всего не повлияет на производительность благодаря наличию нескольких подключений. Хотя это не является специфическим, говорит ли речь о стороне клиента или сервера (кролика). С одной точки зрения, конечно, он будет использовать больше системных ресурсов с большим количеством подключений. Если это не проблема, и вы хотите иметь большую пропускную способность, возможно, будет лучше иметь несколько соединений, поскольку этот пост предполагает, что несколько подключений позволят вам увеличить пропускную способность. Причина в том, что, даже если есть несколько каналов, через соединение только одно сообщение проходит через соединение. Поэтому большое сообщение блокирует все соединение, или многие несущественные сообщения на одном канале могут блокировать важное сообщение в том же соединении, но с другим каналом. Снова ресурсы - проблема. Если вы используете всю ширину полосы пропускания с одним соединением, то добавление дополнительного соединения не будет увеличивать производительность по сравнению с двумя каналами в одном соединении. Также каждое соединение будет использовать больше памяти, процессоров и дескрипторов файлов, но это может не быть проблемой, хотя может быть проблемой при масштабировании.

Ответ 2

В дополнение к принятому ответу:

Если у вас есть кластер узлов RabbitMQ с передним балансиром нагрузки или с недолговечным DNS (что позволяет каждый раз подключаться к другому кролику node), то один, долгоживущий соединение означает, что одно приложение node работает исключительно с одним RabbitMQ node. Это может привести к тому, что один RabbitMQ node будет более активно использоваться, чем другие.

Другая проблема, упомянутая выше, заключается в том, что публикация и потребление - это операции блокировки, что приводит к сообщениям о очередности. Наличие дополнительных соединений гарантирует, что 1. время обработки для каждого сообщения не блокирует другие сообщения. 2. большие сообщения не блокируют другие сообщения.

Вот почему стоит подумать о наличии небольшого пула соединений (имея в виду проблемы с ресурсами, поднятые выше)

Ответ 3

"Один канал на поток" может быть безопасным предположением (я могу сказать, что я не сделал никаких исследований сам, и у меня нет причин сомневаться в документации:)), но будьте осторожны, что есть случай, когда это прерывается

Если вы используете RPC с RabbitMQ Прямой ответ на, вы не сможете повторно использовать тот же канал для использования для другого запроса RPC. Я спросил подробности об этом в группе пользователей google и ответ, который я получил от Майкла Клишина (который, похоже, активно участвует в разработке RabbitMQ) было то, что

Прямой ответ не предназначен для совместного использования каналов.

У меня есть электронная почта Pivotal, чтобы обновить их документацию, чтобы объяснить, как amq.rabbitmq.reply-to работает под капотом, и я все еще жду ответа (или обновления).

Итак, если вы хотите придерживаться "одного канала в потоке", остерегайтесь, так как это не будет работать с Direct reply-to.