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