Измерения RTT заявок TWIME в небоевом тестовом окружении

Здравствуйте.
Хочу поделится результатами замеров раунд трипа заявок, который я проделал на днях на тестовой системе, которая используется для разработки.

В тестовую систему входит
— боевое ПО с транзакционной частью на TWIME
— тестовое ПО эмулятор сервера TWIME
— тестовый стенд в виде двух обычных серверов с прямым Ethernet линком между собой

Все что касается программной и аппаратной составляющей, ОС, языков программирования баз данных и так далее я умалчиваю. Могу лишь сказать, что данная архитектура значительно хуже, чем например аналогичная смартлабовца Viking, который демонстрирует свои измерения и даже иногда сообщает конфигурацию системы.

Предметом тестирования является внутренняя задержка системы при выставлении заявок Order на бижу и при получении ответов Response по протоколу TWIME. В качестве параметров теста используется интервал отправки между сообщениями в мкс и общее количество сообщений при отправке. Задержка считается по формуле Latency = RTT/2 и включает в себя затраты бизнес логики приложения, а также затраты всей сетевой части. Тестирование производится в различных режимах для того чтоб оценить поведение системы в условиях далеких от оптимальных. На мой взгляд, это наиболее интересная часть материала, поскольку в сети не трудно найти много тестов производительности TCP стека различных систем, но все они показывают свои оптимальные значения далеко не в тех условиях, в которых могут работать торговые роботы.

Итак. Первый тест — отправка 20 сообщений подряд.

На графике заметна некоторая нестабильность и относительно высокое среднее значение задержки. Эффект понятен не до конца.

Второй тест — отправка 20 сообщений с интервалом 20 мкс.

Первая заявка уходит со значительной задержкой, затем происходит оптимизация памяти.

Третий тест — отправка 20 сообщений с интервалом 2000 мкс.

То же самое, с увеличение интервала отправки в сто раз ничего не меняется.

Четвертый тест — отправка 20 сообщений с интервалом 20мс.

Средняя задержка незначительно выросла, причина в устройстве работы кешпамяти CPU.

Пятый тест — отправка 20 сообщений с интервалом около 2 сек

Дальнейшее увеличение интервала отправки не приводит к деградации. Средний RTT соответствует значению первых заявок в предыдущих тестах.

Итог.
Тестирование показало нетерпимость системы к условиям, когда сигналы на отправку заявок поступают относительно редко. Ущерб от такой неэффективности может составлять десятки микросекунд и более. Что касается скорости протокола TWIME это наиболее легкий протокол с минимальным временным оверхэдом, издержки на обработку TWIME сообщений составляют сущие пустяки.