Есть ли разница в производительности между пулами соединений или каналов в rabbitmq?
Я новичок в Rabbitmq(и программировании), поэтому заранее извиняюсь, если это очевидно. Я создаю пул для совместного использования между потоками, которые работают в очереди, но я не уверен, следует ли мне использовать соединения или каналы в пуле.
Я знаю, что мне нужны каналы для выполнения реальной работы, но есть ли преимущество в производительности, если один канал подключается к одному (с точки зрения увеличения пропускной способности очереди)? или мне лучше просто использовать одно соединение на приложение и объединять много каналов?
примечание: поскольку я объединяю ресурсы, первоначальная стоимость не имеет значения, так как я знаю, что соединения дороже, чем каналы. Меня больше интересует пропускная способность.
3 ответа
Я нашел это на веб-сайте 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 потребителя на канал.
Это только рекомендации, поэтому вам придется провести некоторое тестирование, чтобы увидеть, что лучше всего подходит для вас.
Эта тема имеет некоторые идеи здесь и здесь.
Несмотря на все эти рекомендации, этот пост предполагает, что он, скорее всего, не повлияет на производительность при наличии нескольких соединений Хотя это не определенно, идет ли речь о стороне клиента или стороне сервера (rabbitmq). С одной стороны, он, конечно, будет использовать больше системных ресурсов с большим количеством соединений. Если это не проблема, и вы хотите увеличить пропускную способность, возможно, лучше иметь несколько подключений, поскольку в этом посте предполагается, что несколько подключений позволят повысить пропускную способность. Причина, по-видимому, заключается в том, что даже при наличии нескольких каналов только одно сообщение проходит через соединение за один раз. Поэтому большое сообщение будет блокировать все соединение, или много неважных сообщений на одном канале может заблокировать важное сообщение на том же соединении, но на другом канале. Снова ресурсы - проблема. Если вы используете всю пропускную способность с одним соединением, то добавление дополнительного соединения не приведет к увеличению производительности по сравнению с наличием двух каналов на одном соединении. Кроме того, каждое соединение будет использовать больше памяти, процессоров и файловых дескрипторов, но это не может быть проблемой, хотя может быть проблемой при масштабировании.
В дополнение к принятому ответу:
Если у вас есть кластер узлов RabbitMQ с балансировщиком нагрузки спереди или короткоживущим DNS (позволяющим каждый раз подключаться к другому узлу кролика), то одно долгосрочное соединение будет означать, что одно Узел приложения работает исключительно с одним узлом RabbitMQ. Это может привести к тому, что один узел RabbitMQ будет интенсивнее использоваться, чем другие.
Другая проблема, упомянутая выше, заключается в том, что публикация и использование являются блокирующими операциями, что приводит к очереди сообщений. Наличие большего количества соединений гарантирует, что 1. время обработки каждого сообщения не блокирует другие сообщения 2. большие сообщения не блокируют другие сообщения.
Вот почему стоит подумать о небольшом пуле соединений (имея в виду проблемы с ресурсами, о которых говорилось выше)
"Один канал на поток" может быть безопасным предположением (я могу сказать, что, поскольку я сам не проводил никаких исследований, и у меня нет оснований сомневаться в документации:)), но следует помнить, что существует случай, когда это нарушается:
Если вы используете RPC с прямым ответом RabbitMQ, вы не сможете повторно использовать тот же канал, чтобы использовать его для другого запроса RPC. Я попросил подробности об этом в группе пользователей Google, и ответ, который я получил от Михаэля Клишина (который, похоже, активно участвует в разработке RabbitMQ), заключался в том, что
Прямой ответ не предназначен для совместного использования каналов.
Я отправил электронное письмо Pivotal, чтобы обновить их документацию, чтобы объяснить, как amq.rabbitmq.reply-to работает под капотом и я все еще жду ответа (или обновления).
Поэтому, если вы хотите придерживаться принципа "один канал на поток", будьте осторожны, так как это не будет работать с прямым ответом.