Лучший онлайн-брокер для работы на бирже
65,61
рейтинг
21 мая 2015 в 15:40

Разработка → Жажда скорости: Оптимизация производительности торгового терминала



Ранее в нашем блоге мы рассказывали о том, зачем трейдеры на фондовом рынке используют торговые терминалы, и представили историю разработки собственного терминала SmartX.

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

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

Зачем ускорять терминал


Необходимость ускорения работы терминала SmartX назрела по двум причинам — часто трейдеры запускают торговый софт на переносных устройствах (ноутбуках, планшетах под Windows), не на самых мощных «офисных компьютерах» или просто старых машинах.

При этом активность на рынке год от года только увеличивается, и в условиях, к примеру, сильных движений или так называемых “panic-sale” в дни выхода важных экономических новостей, количество рыночных данных (market data), отправляемой сервером терминалу, может в короткие сроки возрастать в десятки раз. Если программа запущена на слабом устройстве, то может просто зависнуть в самый ответственный момент, что может вылиться в потерю денег пользователем.

Кроме того, на рынке существует целый класс активных трейдеров (например, «скальперы», арбитражеры и high frequency-трейдеры), которые даже в обычный торговый день осуществляют большое количество заявок и сделок. Такие торговцы редко используют GUI-терминалы для непосредственной торговли, но часто применяют подобный софт для контроля своих позиций, однако большое количество генерируемых ими данных даже мощный компьютер может «не переварить».

Торговый терминал ни в коем случае не должен становиться «узким» местом в цепочке «трейдер-биржа», поэтому работы по его улучшению и оптимизации производительности нужно проводить постоянно.

Как устроен терминал


Прежде чем погрузиться в описание процесса оптимизации терминала, следует разобраться в том, какие компоненты включает такое программное обеспечение. (Чтобы не задерживать тех, кому интересен сам процесс оптимизации, мы убрали эти подробности под спойлер).

Как все устроено
Торговый терминал SmartX состоит из протокольной и терминальной частей.

Первая из них отвечает за «общение» с серверами брокерской торговой системы (Matrix — о ней у нас был отдельный материал) — она «мержит» все входящие потоки данных в один поток сообщений. Соответственно, протокольная часть является многопоточной. Написана она на C++.

Терминальная часть с заданным периодом опрашивает получившуюся очередь сообщений и делает необходимые расчеты для отображения информации пользователю. Этот софт является однопоточным и написан на C#. (В нашем блоге также опубликовано интересное интервью с разработчиков SmartX о том, почему C# и C++ так популярны на фондовом рынке.)

Основные концепции оптимизации


Теперь рассмотрим подробнее использовавшиеся методики оптимизации производительности.

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

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

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

До внедрения подобной технологии в моменты пиковых нагрузок терминал мог начинать запаздывать и отображать «исторические» данные, а GUI в такие моменты вообще мог подвиснуть, не справившись с обработкой больших массивов данных.

Следующим этапом оптимизации стало снижение memory traffic. Узким местом в этом механизме, как известно, является GarbageCollection, поэтому разработчиками терминала был реализован собственный memory management для тех объектов и коллекций, которые часто создаются или обновляются. С его помощью удалось снизить количество сборок мусора при работе терминала, а следовательно — улучшить его производительность

В результате GUI не подвисает во время сборки «мусора», также это позволяет терминалу работать неограниченное количество времени без перезагрузки — используемое количество памяти при этом не растет.

Стало ли лучше: тест


Для проверки того, насколько лучше стал работать торговый терминал, на тестовом контуре брокерской торговой системы был запущен стресс-тест, состоящий в запуске генератора нагрузочного потока данных — 1000 тиков, 1000 стаканов и 1000 изменений котировок («квот») в секунду.



Часть теста: открытие в терминале большого количества стаканов по инструменту (более 40)

На компьютере Celeron G460 1.8GHz 2Gb сравнивались следующие версии терминалов:

  • 5.2.107 – версия без какой либо оптимизации
  • 5.3.170 – текущая актуальная версия
  • 5.3.184 – релиз-кандидат продакшен-версии 5.4.0

По итогу теста были получены следующие результаты:

  • Версия 5.2.107 – загрузка процессора 60-75%, GUI не отвечает (на скриншотах серый общий фон программы), терминал не реагирует на действия пользователя;


  • Версия 5.3.170 — загрузка процессора 60-75%, GUI не зависает, терминал с задержкой, но реагирует на действия пользователя;
  • Релиз-кандидат 5.3.184 – загрузка процессора не выше 15%, терминал сразу реагирует на все действия пользователя.

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

На сегодня все, спасибо за внимание! На забывайте подписываться на наш блог.
Автор: @itinvest
ITinvest
рейтинг 65,61
Лучший онлайн-брокер для работы на бирже

Комментарии (9)

  • +1
    Надеюсь, разработчики X-Lite прочитают эту статью и сделают выводы
  • +1
    Однажды попробовал силы на Forex'е. Стратегию выбрал — пипсование. Операции относительно частые, но небольшие по размеру. Т.е. как курочка по зернышку. Зато без риска потери значительной части своих средств — по-сути без просадок (тот самый манименеджмент). Написал бота, который открывал операции автоматически при выполнении некоторых условий. Начал как и полагается — с демосчета. И получилось! В течении месяца каждую неделю удваивал капитал. Просадок нет, все стабильно. Ну ведь это шоколадно! Попробовал выйти в реал. Ну и полный облом… Робот при совпадении условий выдавал команду без задержек как и раньше. Но вот основное различие между демо и реал-счетом с скорости реакции торгового оператора. На демосчете как дал команду, так операция и открылась. В реале на команду открытия операции проходило довольно много времени (секунды). За это время значение курса немного менялось, и операция теряла смысл. Т.е. временной лаг между командой на открытие (и по-моему закрытия) и исполнением операции на рынке, привел к срыву стратегии работающей на демосчете.
    Как я понимаю, скорость реакции на команды с терминала очень важны для пипсовщиков (и статья больше для них), и не столь важны для стратегических инвесторов. А как сейчас обстоит дело со скоростью проведения операций для рядовых клиентов?
    • +2
      Сейчас в торговой системе Matrix минимальное время выполнения заявки 5мс, но тут многое еще зависит от каналов связи клиента. А вообще, не нужно было, конечно, на Forex ходить
  • 0
    Давно уже видел ваш SmartX последний раз, так что вопрос тут насчет скорости работы GUI — будет ли зависать отрисовка если для окна с терминалом быстро-быстро изменять размер? То есть если взять край окна мышкой и перемещать её достаточно быстро.
    • 0
      Отрисовка не зависает. Да конечно, нагрузка на процессор возрастает, но не более чем при таких же действиях в другом приложении, например Skype. Вы и сами это можете проверить)
  • 0
    Советую Вам ознакомиться с продуктом Intel VTUNE, и оптимизировать в первую очередь «горячие точки» терминала. На Хабре есть хорошие статьи по этому инструменту. Может, напишете вторую часть к этой статье )
    • 0
      Спасибо за совет про Intel — мы с ним знакомы, это действительно крутой продукт для профилирования приложений. Но поскольку основная часть нашего терминала написана на C#, то мы в своей работе используем JetBrains dotTrace. Данный продукт заточен именно под .Net
  • 0
    Эти тесты что-то сродни «Ага, я могу открыть 100500 стаканов, 3000 графиков, и при этом кодировать 1080p видео и все это на нетбуке на Intel Atom и у меня не будет ничего тормозить.»
    Вопрос в том, а для чего? Столько статики нужно если только роботам, а для них gui вообще не важен.
    Человеко-часы лучше бы направить в сторону серверного по, репликацию между серверами настроить, подкрутить стопы…
    • 0
      Человеко-часы были успешно потрачены на решение ключевой проблемы терминала, а именно «подтормаживание» во время больших движений на рынке, во время которых трейдеру обычно необходимо принимать ключевое решение (а терминал подводил).

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разработка