Главная » Хабрахабр » [Из песочницы] Производительность торговой платформы на простом примере

[Из песочницы] Производительность торговой платформы на простом примере

Для справки речь идет о временах от сотен наносекунд до сотен микросекунд. В этой статье я хочу в научно-популярной форме рассказать об оптимизации времени отклика в торговых платформах бирж и банков (HFT). Для большинства других приложений многие приведенные ниже методы оптимизации неактуальны просто в силу отсутствия столь жестких требований.

Например в Гигафлопах. Обычно мы рассматриваем производительность в единицах пропускной способности. Дизайн процессора рассчитан в первую очередь на достижение максимального количества вычислений за единицу времени и стандартные техники оптимизации на то же самое. Задача оптимизации в таких случаях сводится к выполнению максимального количества вычислений за единицу времени или решение задачи за минимальное время.

Время отклика – это время выполнения «единичной» операции данного типа, например от получения пакета с текущими котировками с биржи до посылки заказа на биржевую операцию. Однако существуют приложения где важнее время отклика, например торговые платформы в компьютерном трейдинге (HFT), поисковики, робототехника и телеком. Увеличить пропускную способность часто можно просто добавив железа (больше серверов), но улучшить время отклика подобным образом проблематично (кроме случаев пиковых нагрузок). На самом деле время отклика и пропускная способность (количество операций данного типа в единицу времени) тесно связаны, но разница – принципиальна.

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

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

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

Работа офиса

Представьте группу людей работающих в офисе. Давайте воспользуемся следующей аналогией. Каждое письмо содержит адресата, отправителя и задание. Коммуникации происходят посредством обмена сообщений на бумажном носителе (писем). Есть работники, задача которых – получать письма из внешнего мира и класть их на столы. Письма кладутся на определенные столы в офисе. Каждый принимающий решения работает только с определенным типом писем (или заданий). Другие забирают письма со столов и передают их тем, кто принимает решения.

Задания к выполнению складываются на отдельный стол. Принимающий решения читает предназначенные ему письма и решает будет ли выполнено данное задание, отложено или проигнорировано. На некоторые письма надо отвечать вовне офиса, например послать внешнему отправителю подтверждение. Специальные работники забирают письма с этого стола и раздают исполнителям.

Например, офис представляет собой сложную сеть комнат и коридоров и разным типам работников можно ходить только в определенные места, куда у них оформлен доступ. Чтобы быть ближе к реальности давайте еще немного усложним условия. Как говорят математики, не нарушая общности, предположим что наш офис при нормальных условиях обрабатывает 200 сообщений в день при среднем времени обработки сообщения в 5 минут.

При этом желательно, чтобы максимальное время обработки не превышало среднее более чем, скажем, вдвое. Итак, наша задача – максимально сократить время обработки сообщений. То есть всплески активности должны быть эффективно обработаны.

Проще всего нанять больше работников чтобы обрабатывать больше сообщений. Итак, с чего начнем? Допустим, мы наняли Усейна Болта и других финалистов Олимпийских игр. Неплохо поискать быстрых работников, тогда сократится время обработки. Но очевидно, что в этом направлении двигаться дальше некуда. Возможно время обработки снизилось до 2 минут. Предел достигнут. Быстрее не бегает никто. Найм спортсменов аналогичен покупке максимально быстрого железа (максимальная частота в первую очередь). Сравнивая эти подходы с компьютером, найм людей есть покупка дополнительного железа (сервера, процессоры, ядра) чтобы увеличить количество потоков исполнения.

Надо обеспесить достаточно места, чтобы работники работали эффективно. Возможно планировка нашего офиса не оптимальна. Давайте расширим. Может быть расширить коридоры, а то людям приходится уступать друг другу дорогу теряя драгоценное время? Это все равно что купить сервера с большим количеством ядер и большей пропускной способностью памяти и ввода/вывода. Давайте также слегка увеличим комнаты чтобы люди не толпились при подходе к столам.

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

Можно еще потренировать работников для улучшения процесса коммуникации и исполнения. Итак, после нововведений, наше время обработки сообщений упало до, допустим, одной минуты. Знасит мы достигли 51 секунды. Возможно это даст процентов 15 при правильной мотивации. Это похоже на оптимизацию программного обеспечения.

Вероятное узкое место – подход к столам. Следующим шагом постараемся избежать столкновений наших быстро бегающих работников. Можно сортировать сообщения на столах при выкладке (класть в отдельные папки) чтобы ускорить доступ. Желательно, чтобы работники имели мнгновенный и одновременный доступ к нужным им столам. В программе это аналог синхронизации потоков. Сообщения могут также иметь разный приоритет. Исправление проблем с синхронизацией потоков часто дает огромный рост пропускной способности системы и помогает улучшить время отклика. Потоки должны иметь неограниченно параллельный и максимально быстрый доступ к данным. В смысле обработки всплесков активности влияние оптимального алгоритма синхронизации вообще трудно переоценить.

Другие мелкие проблемы подобного свойства могут вызвать неудобства и задержки. Помимо этого, работники иногда могут оказаться перед закрытой дверью. В компьютерных терминах это означает, что количество потоков никогда не превышает количество доступных ядер, платформа настроена на максимальную частоту/производительность, экономные режимы отключены, режим Турбо включен и работа ядра операционной системы и других приложений изолирована и (почти) не влияет на торговую платформу. Желательно выполнить следующие условия: количество людей в данном помещении никогда не превышает его вместимости, скорость работников ничем не ограничена, никаких не относящихся к основной работе действий не производится и никто посторонний не влезает в процесс работы.

Открываются ли двери легко? Теперь пора рассмотреть еще внимательнее условия в офисе. Это примерно тоже самое что анализ взаимодействия с операционной системой. Не скользит ли пол? Например, вместо того чтобы разносить письма через офис, почему бы не попробовать кидать их из окна в окно? Если улучшить уже нечего, можно попытаться избежать использования некоторых частей. Может и неудобно, зато быстро. Скажете неудобно? Это аналог использования подхода kernel bypass в сетевом стеке.

Это помогает избавиться от ненужных копирований данных между стеком системы и пользователя и задержки исполнения потока получения сообщения. Вместо использования сетевого стека операционной системы, kernel bypass исполняет сетевой стек в user space. Он не сидит на локе операционной системы, а непрерывно проверяет переменную лока до тех пор пока она не даст ему разрешение на исполнение. В kernel bypass поток получения обычно ждет активно.

Наиболее надежный вариант это передать через окно из рук в руки. На самом деле если уж мы начали бросать сообщения через окна, давайте сделаем это эффективно. Это не самый быстрый вариант. Этот принцип используется в TCP протоколе. Это быстрее. UDP разрешает просто бросить сообщение без подтверждений. Думаете это предел? Никого ждать не требуется. Такой подход называется remote direct memory access (RDMA). Нет, можно еще научиться бросать через окно так, чтобы письмо падал прямо на нужный стол и в нужную папку. Думаю, мы понизили время обработки секунд до 35-ти.

Такой, чтобы обеспечивал идеальные условия работы. А может быть построить офис с нуля вместо того чтобы приспосабливать существующий к нашим нуждам? Собственный дизайн офиса – это использование field programmable gate array (FPGA). Наверное это позволит улучшить время отклика секунд до 20-ти, а то и меньше. Обычный процессор закодирован на выполнение определенного набора инструкций на определенных типах данных и поток исполнения (не путать с потоком приложения) тоже фиксирован. FPGA – это нечто вроде процессора, железо которого программируется под решение конкретной задачи. Они программируются под конкретную задачу и в таком состоянии способны исполнять только ее (до последующего перепрограммирования). В отличии от процессора, FPGA не запрограммированы заранее под набор инструкций, типов данных и поток исполнения. Внесение изменений в программу также может потребовать больших усилий. Эффективное программирование FPGA – не самая простая задача. И хотя FPGA не подразумевает найм Усейна Болта (частоты намного ниже, чем процессорные), но неограниченный параллелизм исполнения инструкций позволяет добиваться более низких времен обработки сообщений, чем на процессоре.

Intel VTune TM Amplifier и Intel Processor Trace technology помогут увидеть в деталях где и почему тратится процессорное время. Ну и в заключение порекомендую инструменты анализа производительности для программного обеспечения.

Если есть интерес к теме, можно почитать мои статьи на Intel Developer Zone (на английском), где также приводятся практические технические советы по оптимизации времени отклика.

  • https://software.intel.com/en-us/articles/optimizing-computer-applications-for-latency-part-1-configuring-the-hardware
  • https://software.intel.com/en-us/articles/optimizing-computer-applications-for-latency-part-2-tuning-applications

Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

Такая боль, такая боль, сервис на аутсорсе 1:0

В идеальном мире мы бы занимались только разработкой и развитием системы. Мы делаем самую лучшую в России и ближнем зарубежье систему обнаружения заимствований. Наш софт пока не работает без железа, пользователям нужно оказывать техническую поддержку, получать оплату от пользователей необходимо ...

Типовые ошибки пассажиров железных дорог и авиалиний

Мы вторая линия поддержки пассажиров. Привет! Я очень хочу рассказать, что может пойти не так, так как очень надеюсь, что это спасёт чьи-то нервы. Каждый день мы обрабатываем сотни ошибок в билетах. По крайней мере, мы постоянно сталкиваемся с проблемами ...