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