MTB ESB Documentation

Performance testing

План проверки пропускной способности и стабильности E2E-цепочки Stronghold и D8.

Performance testing

План тестирования проверяет пропускную способность, latency, error rate и восстановление полного маршрута:

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

Численные SLO ещё не согласованы

Confluence export от 19 августа 2026 определяет методику, но не содержит утверждённых значений RPS, latency и error rate. Не используйте предполагаемые числа как acceptance criteria.

Что согласовать до теста

Банк и владельцы сервиса должны зафиксировать:

  • ожидаемый средний RPS;
  • максимальный и пиковый RPS;
  • целевой percentile успешных запросов — p95 или p98;
  • допустимый latency в миллисекундах;
  • допустимый error rate;
  • длительность steady-state нагрузки и критерии recovery.

Preconditions

  • Stage/pre-production развёрнут полностью и максимально близок к Production;
  • async flow с Callback Service реализован;
  • внешние Stronghold и D8 endpoints можно заменить управляемыми mocks;
  • test data не содержит production secrets или реальных чувствительных данных;
  • dashboards, traces, logs и alerts доступны всем участникам теста;
  • известны версии WSO2, Router, adapters и конфигурации окружения.

Без первых трёх условий результат не позволяет изолировать adapter и оценить E2E-цепочку корректно.

Сценарии

СценарийНазначениеМинимальный результат
BaselineПроверить стабильность на ожидаемой средней нагрузкеRPS, p50/p95/p98 latency, error rate и resource usage
Ramp-upПошагово увеличивать нагрузку до деградацииТочка saturation, первый bottleneck и поведение очередей
Peak + RecoveryСоздать кратковременный пик и вернуть baselineRecovery time, backlog drain и отсутствие потери/дублирования

Peak + Recovery указан в исходном плане как опциональный, но необходим перед Production readiness для критичных flows.

Наблюдаемые сигналы

  • WSO2 request rate, latency, throttling и 4xx/5xx;
  • Router processing time, outbox size и retry count;
  • Kafka produce latency, consumer lag и partition distribution;
  • adapter latency, connection pools, retries и DLT volume;
  • external service latency/error rate или параметры mock;
  • callback delivery latency, retries и failures;
  • CPU, memory, restarts, GC и saturation каждого компонента.

Отчёт о тесте

Зафиксируйте environment, versions, dataset, load profile, результаты по каждому сценарию, bottleneck, recovery behavior и решение PASS, PASS WITH LIMITATIONS или FAIL. Для каждого ограничения назначьте owner и повторный test date.

On this page