Каковы минимальные возможные задержки для механизма FIX для отправки сообщения FIX от клиента к серверу?

Ганнибал анте портас! . . . не теряйте времени на оптимизацию в неположенном месте

Для принципиально низких достижимых чисел не забудь проверить ASIC / FPGA — основанные на FIX-протоколе решения. Любая последовательная / параллельная последовательная обработка имеет трудные времена, чтобы стать быстрее, чем решение с параллельным кремниевым двигателем.

Можно достичь не намного глубже, чем о 25 ns разрешение по измерению на основе кода aStopwatch.start();callProcessUnderTest();aStopwatch.stop() но реальные проблемы и проблемы находятся где-то еще.

Чтобы иметь некоторое сравнение по этому вопросу, 20 ns задержка составляет всего 5 м AOC / активных оптических кабелей в межсоединениях 120 Гбит / с в колокейшн-центрах / кластерах HPC.

0: Определите СПРАВОЧНЫЕ ТОЧКИ: избегайте сравнения апельсинов с яблоками

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

На первый взгляд, спрашивая мир о «Наименьшем возможном» что-нибудь«звучит привлекательно, если не сексуально, как это часто слышно в недавних СМИ, однако любая серьезная попытка ответить на сказанное «Самый низкий возможный» трудно без надлежащего ухода, потраченного на устранение неоднозначности проблемы (если даже не демистификация (особенно во избежание сгенерированных MAR / COM обещаний получить Ответы до того, как кто-то спросит / Instant Kharma / Eternal Heaven и др., вы знаете их достаточно хорошо, чтобы упоминать их больше)).

Под солнцем нет ничего нового, что именно по этой причине МСЭ-Т / МСЭ-R и более поздние IETF приложили огромные усилия для систематической заботы об определении спецификаций, чтобы избежать любого потенциального недопонимания, тем меньше неправильных толкований (будь то в определения стандартов или процедур приемочного тестирования или спецификации минимальных эксплуатационных характеристик, которым должен соответствовать продукт / услуга, чтобы они были полностью совместимыми).

Так прежде чем принимать любую фигуру, будь то в [мс], [нас] или [нс], быть конечно есть ли у всех нас та же справочная установка System-Under-TЕсть и быть дважды уверил для которых две опорные точки [FROM]-[TO] представленная цифра была фактически измерена.

1: Определить сценарий теста (включая сообщение протокола FIX) Сквозной конец

________________________________________________________________________
+0 [us]-[__BaseLINE__] a decision to send anything is made @ <localhost>
|
|- <localhost> process wishes to request
|                                a FIX-MarketData
|                                Streaming Updates
|                                for a single item EURCHF
|                                during LON session opening time
|
|- <localhost> process wishes to request
|                                a FIX-MarketData
|                                Single FullRefresh
|                                for an itemset of:
|                                { EURUSD, GBPUSD, USDJPY,
|                                  AUDUSD, USDCAD, USDCHF }
|                                during LON session opening time
|
+  [us]-o======< REFERENCE POINT[A] >===================================
|
|- transfer all DATA to a formatting / assembly process-entity
|
+  [us]-o======< REFERENCE POINT[B] >===================================
|
|- completed a FIX-message payload to be sent
|
+  [us]-o======< REFERENCE POINT[C] >===================================
|
|- completed a FIX-message Header/Trailer/CRC to dispatch
|
+  [us]-o======< REFERENCE POINT[D] >===================================
|
|- inlined SSH/DES/AES cryptor communication service processing
|
+  [us]-o======< REFERENCE POINT[E] >===================================
|
|- L3/2 transport service protocol SAR / PMD
|
+  [us]-o======< REFERENCE POINT[F] >===================================
|
|- L2/1 PHY-device wire-on/off-load process ( NIC / FPGA )-engine
|
+  [us]-o======< REFERENCE POINT[G] >===================================
|
|- E2E transport xmit/delivery processing / latency
|
+  [us]-o======< REFERENCE POINT[H] >===================================
|
|- L1/2 PHY-device on "receiving"-side wire-on/off-load process
|
+  [us]-o======< REFERENCE POINT[I] >===================================
|
|- L2/3 transport recv/handshaking processing / latency
|
+  [us]-o======< REFERENCE POINT[J] >===================================
|
|- inlined SSH/DES/AES decryptor processing
|
+  [us]-o======< REFERENCE POINT[K] >===================================
|
|- incoming FIX-message Header/Trailer/CRC check-in
|
+  [us]-o======< REFERENCE POINT[L] >===================================
|
|- authentication / FIX-Protocol message-counter cross-validation
|
+  [us]-o======< REFERENCE POINT[M] >===================================
|
|- FIX-message requested service content de-mapping
|
+  [us]-o======< REFERENCE POINT[N] >===================================
|
|- FIX-message requested service execution / handling
|
+  [us]-o======< REFERENCE POINT[O] >===================================
|
|- FIX-message requested service response pre-processing / assy
|
+  [us]-o======< REFERENCE POINT[P] >===================================
|
[__FinishLINE__] Ready To Send anything back to <localhost>
|
+  [us]-o======< REFERENCE POINT[Q] >===================================
________|_______________________________________________________________

: SUBTOTAL BEFORE A REQUESTED SERVICE'S RESPONSE-DELIVERY STARTS
________________________________________________________________________

В качестве вдохновения попытайтесь представить что-то похожее на единую структуру отчетов о задержках для всех поставщиков (или для ваших внутренних разработчиков / команд тестирования проекта), как этот пример.

2. Определите ПОЛНЫЙ КОНТЕКСТ (включая когда / какие фоновые параллельные действия (рабочая нагрузка / шум) вы тестируете)

Если вам нужны минимальные задержки, клиент FIX и сервер FIX должны находиться на одном сервере, даже в одном приложении, используя решение IPC, такое как разрушитель

Я присутствовал на презентации Сингапурской фондовой биржи несколько лет назад. Они недавно приобрели платформу Nasdaq OMX и заявили, что наименьшее время совпадения составило около 8 микросекунд, если сообщения отправлялись по собственному протоколу. Затем они сказали, что поддерживают FIX, что приведет к 2-3 микросекундам сверх времени сопоставления …

Я полагаю, вы можете использовать это число 2-3 микросекунды как своего рода минимальные накладные расходы FIX, которых может достичь биржа, претендующая на самый быстрый результат 🙂