Скорость передачи RabbitMQ ускоряется?

Question

Я ищу идеи, как ускорить передачу сообщений через RabbitMQ.

Я установил последнюю версию на 64-разрядной версии Windows, запустив сервер на своей локальной машине, на которой я также публикую и потребляю/из реализации C#. Я изначально максимизировал 40 000 сообщений в секунду, что впечатляет, но не соответствует моим потребностям (я конкурирую с пользовательским двоичным считывателем, который может обрабатывать 24 миллиона нераспакованных 16-байтных массивов больших байт в секунду, очевидно, я не ожидаю, что приблизиться к этому, но Я пытаюсь улучшить как минимум). Мне нужно отправить около 115 000 000 сообщений как можно быстрее. Я не хочу сохранять данные, и соединение будет направлено на одного единственного потребителя. Затем я построил куски моих 16-байтовых массивов и опубликовал их на автобусе без каких-либо улучшений. Скорость передачи максимальная - 45 мб/с. Я нахожу это очень медленным, учитывая тот факт, что в конце концов он должен просто сводиться к необработанной скорости передачи, потому что я мог создавать массивы байтов размером в несколько мегабайт, где коэффициент эффективности маршрутизации на бирже становится незначительным по сравнению со скоростью передачи. Почему моя максимальная пропускная способность моего сообщения составляет скорость передачи данных 45 Мбит/с?

Answer 1

Bump ... и обновление: не видели ответа на этот вопрос в течение более длительного времени. Я немного удивлен, что ни один разработчик RabbitMQ не зашел в игру. Я много играл с RabbitMQ и ZeroMQ. Я решил, что RabbitMQ не справляется с задачей при рассмотрении высокопроизводительных решений для обмена сообщениями в процессе. Реализация брокера и особенно логика синтаксического анализа являются основным узким местом для повышения пропускной способности. Я сбросил RabbitMQ из списка возможных вариантов.

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

ZeroMQ, сделал великолепную работу после того, как я изучил документацию более интенсивно. Я могу запустить взаимодействие в процессе, он обеспечивает достаточно стабильные шаблоны push/pull, pub/sub, req/rep и пары/пары, которые мне нужны. Я искал логику блокировки внутри шаблона pub/sub, который ZeroMQ не предоставляет (вместо того, чтобы превышать высокий водяной знак), но шаблон push/pull обеспечивает блокировку. Таким образом, мне нужно все, что мне нужно. Единственная проблема, с которой я сталкиваюсь, заключается в понимании обработки событий; реализация структуры событий через опрос/мультиплексирование не очень удовлетворительна.