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

Question

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

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

Answer 1

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

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

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