📺 Нагрузочное тестирование BPM: процесс vs движок

Есть два подхода — и у каждого своя задача. Важно понимать, что это не альтернативы, это два разных инструмента: один показывает поведение системы целиком, а второй — пределы и деградации самого движка.

Если использовать только один — вы теряете часть картины.

📝Как строить нагрузочное тестирование

1. Сначала синтетика (движок)
Цель — получить baseline.

Что делаем:
• фиксируем rate (например, N процессов/сек)
• используем упрощённый процесс (параллелизм + async задачи)
• убираем внешние вызовы

Что получаем:
• стабильный throughput
• понятную зависимость от CPU/конфигурации
• возможность сравнивать версии

На этом этапе важно:
• не менять сразу несколько параметров
• фиксировать конфиг (пулы, потоки, history)
• смотреть на перцентили latency, а не среднее

2. Потом бизнес-процесс
Цель — проверить реальное поведение.

Что делаем:
• включаем интеграции
• используем реальные payload’ы
• моделируем пользовательский поток

Что ищем:
• деградации SLA
• нестабильность интеграций
• рост latency на отдельных шагах

3. Сравнение результатов
Ключевой момент, который часто упускают.

Типовые ситуации:
• синтетика стабильна, бизнес деградирует → проблема вне движка
• синтетика падает → проблема в ядре или конфигурации
• оба теста деградируют → системная проблема (чаще CPU/БД)

👨‍💻 Практические рекомендации

✅Всегда фиксируйте baseline для синтетики (без него нет регрессии)
✅Не используйте burst-нагрузку без контроля — она ломает метрики
✅Следите за CPU: в BPM он почти всегда первый bottleneck
✅Учитывайте history level — он может “съесть” производительность
✅Не доверяйте тестам, где всё упирается в I/O — это уже не про движок

🫡 Вывод
• Синтетика нужна, чтобы контролировать производительность платформы.
• Тест бизнес-процесса — чтобы понимать реальное поведение системы.

Только связка этих подходов даёт нормальную картину.