Сокеты Java на RDMA (JSOR) и производительность jVerbs в Infiniband

Question

У меня есть базовое понимание как JSOR, так и jVerbs.

Оба обрабатывают ограничения JNI и используют быстрый путь для уменьшения задержки. Оба они используют пользовательский интерфейс RDMA Verb для избежания переключения контекста и обеспечения быстрого доступа. У обоих также есть варианты для передачи нулевой копии.

Разница в том, что JSOR все еще использует интерфейс Java Socket. JVerbs предоставляет новый интерфейс. У jVerbs также есть то, что называется Stateful Verbs Call, чтобы избежать повторной сериализации запросов RDMA, которые, по их словам, уменьшают задержку. jVerbs предоставляет более родной интерфейс, и приложения могут напрямую использовать их. Я прочитал статью jVerbs SoCC 2013, в которой они строят jverbsRPC поверх jVerbs и показывают, что это значительно уменьшает задержку операций zookeeper и memcache.

Документация для обоих показывает, что они работают лучше, чем обычные сокеты Java на основе TCP/IP, SDP и IPoIB.

У меня нет сравнения производительности между JSOR и jVerbs. Я думаю, что jVerbs может работать лучше, чем JSOR. Но с JSOR мне не нужно менять существующий код, потому что он все еще использует тот же интерфейс сокетов Java. Мой вопрос заключается в том, что может быть увеличение производительности использования jVerbs по сравнению с JSOR. Кто-нибудь знает или имеет опыт работы с этими двумя? Если у вас есть сравнительные данные, это будет здорово. Я не мог найти ни одного.

Answer 1

Вот несколько примеров использования DiSNI - недавно открытого источника IBM jVerbs - и DaRPC, RPC-библиотеки с низкой задержкой, использующей DiSNI.

• Задержка чтения DiSNI RDMA для 64 байтов меньше 2 микросекунд
• Задержки отправки / возврата DaRPC RDMA для 64 байтов (запрос и ответ) составляют около 5 микросекунд
• Различия между RDMA для Java / DiSNI и C незначительны для односторонних операций

Эти тесты были выполнены на двух хостах, подключенных с использованием сетевого интерфейса Mellanox ConnectX-3.

Вот команды для выполнения тестов:

(1) Читать тест

Сервер:

java -cp disni-1.0-jar-with-dependencies.jar:disni-1.0-tests.jar com.ibm.disni.examples.benchmarks.AppLauncher -t java-rdma-server -a <address> -o read -s 64 -k 100000 -p

Клиент:

java -cp disni-1.0-jar-with-dependencies.jar:disni-1.0-tests.jar com.ibm.disni.examples.benchmarks.AppLauncher -t java-rdma-client -a <address> -o read -s 64 -k 100000 -p

(2) отправка / получение контрольных показателей

Сервер:

java -cp darpc-1.0-jar-with-dependencies.jar:darpc-1.0-tests.jar com.ibm.darpc.examples.server.DaRPCServer -a <address> -d -l 64 -r 64 

Клиент:

java -cp darpc-1.0-jar-with-dependencies.jar:darpc-1.0-tests.jar com.ibm.darpc.examples.client.DaRPCClient -a <address> -k 1000000 -l 64 -r 64 -b 1

Answer 2

Трудно сравнить производительность jVerbs против JSOR. Первый - это API, ориентированный на сообщения, а второй скрывает RDMA за потоковым API сокетов Java.

Вот некоторые характеристики. Мой тест проводился с использованием пары старых карт ConnectX-2 и серверов Dell PowerEdge 2970. CentOS 7.1 и Mellanox OFED версии 3.1.

Меня интересовал только тест на задержку.

jVerbs

Test - это разновидность RPing-примера (можете публиковать на github, если кому-то интересно). Проверьте измеренную задержку 5000000 циклов следующей последовательности вызовов через надежное соединение. Размер сообщения был 256 байтов.

PostSendMethod.execute()
PollCQMethod.execute()
CompletionChannel.ackCQEvents()

Результаты (микросекунды):

• Медиана: 10,885
• Процентиль 99,0%: 11,663
• Процентиль 99,9%: 17,471
• Процентиль 99,99%: 27,791

JSOR

Подобный тест через сокет JSOR. Тест был образцом сокета клиент / сервер учебника. Размер сообщения также составлял 256 байт.

Результаты (микросекунды):

• Медиана: 43
• Процентиль 99,0%: 55
• Процентиль 99,9%: 61
• Процентиль 99,99%: 217

Эти результаты очень далеки от теста латентности OFED. На том же оборудовании / стандарте ОС эталон ib_send_lat показал 2.77 в качестве медианы и 23.25 мкс в качестве максимальной задержки.