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

Вот некоторые из основных показателей, которые необходимо определить, согласовать и контролировать:

  • Пропускная способность — скорость работы, которую может выполнять система. Торговое приложение загружается из-за большого количества запросов/ответов, полученных в начале дня/после обеда и в конце рынка. Торговое приложение «xyz» может обрабатывать ‹15000 запросов за 1 секунду во время пиковых случаев.
  • Задержка — время, необходимое для обработки одной транзакции и наблюдения за результатом. Все запросы, обрабатываемые приложением, должны документироваться и отслеживаться. Торговое приложение «xyz» отправит ордер на обмен за 1 миллисекунду в 95-м процентиле и 6 миллисекунд в 100-м процентиле.
  • Емкость — количество единиц работы, таких как транзакции, которые могут одновременно выполняться в системе. Торговое приложение «xyz» сможет обрабатывать 1 миллион запросов в течение всего торгового дня, не влияя на заданную пропускную способность или задержку.
  • Использование ключевых метрик — ЦП/память/дисковый ввод-вывод/сетевой ввод-вывод/время и частота сбора мусора/количество потоков/отклонение времени входящего запроса — их мониторинг поможет легко отслеживать неоптимальные случаи.

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

Все эти метрики можно построить путем захвата или регистрации запросов, поступающих в приложение, с такими подробностями, как имя действия (новый/изменить/отменить/dfd), время начала-окончания, продолжительность, время отправки сообщения из восходящего потока. Эта информация может быть асинхронно обработана с использованием стека #ELK/ или блокнота #Python #Jupyter или с использованием базы данных временных рядов, такой как #Prometheus, и построения графика с помощью #Grafana, как показано ниже.

Графическое/текстовое представление метрик поможет отслеживать производительность приложения и настраивать его на новый уровень. Это можно использовать в качестве критерия выхода для разработки, обеспечения качества и одобрения пользователем для отслеживания производительности приложения.