Сравнительный анализ производительности Платформа 7.24-FZ и Camunda 7.24.0

1. Краткие выводы и ключевые результаты

1.1. Цель исследования

Целью данного нагрузочного тестирования являлась оценка влияния на производительность и стабильность системы переноса механизма записи истории из традиционной базы данных (PostgreSQL) в быструю очередь сообщений (Apache Kafka). Мы сравнивали две системы: стандартную версию Camunda 7 и Платформа 7, где история выполнения процессов отправляется в Kafka. Тестирование проводилось с уровнем историчности full, так как именно этот режим генерирует наибольшее количество операций записи в базу данных.

1.2. Основной вывод

Архитектурное изменение, реализованное в Платформе, привело к повышению не только пиковой производительности, но и, что более важно, стабильности системы под высокой нагрузкой. Хотя Платформа продемонстрировала способность обрабатывать на 7% больший поток процессов в секунду (150 PPS против 140 PPS), ключевым преимуществом стала её устойчивость к перегрузкам.

В отличие от Camunda 7, которая при превышении предела производительности демонстрирует резкое падение успешности выполнения процессов, Платформа деградирует значительно плавнее. Это обеспечивает большую предсказуемость и надежность системы в реальных условиях эксплуатации. Одновременно с этим была зафиксирована разгрузка базы данных PostgreSQL, что подтверждает гипотезу о том, что именно интенсивная запись истории в БД является основным фактором, ограничивающим производительность и стабильность стандартной архитектуры Camunda 7.

2. Методология и среда тестирования

Для обеспечения объективности и воспроизводимости результатов обе платформы тестировались в идентичных условиях по единому сценарию.

2.1. Сценарий тестирования

Тестирование проводилось по сценарию ступенчатого увеличения нагрузки. Начиная со 100 PPS (процессов в секунду), нагрузка росла на 10 PPS каждые 6 минут. Каждая ступень включала в себя 1 минуту для выхода на новый уровень и 5 минут стабильной нагрузки, в течение которых производился сбор метрик.

2.2. Тестируемый бизнес-процесс

Для тестирования использовался типовой BPMN-процесс с последовательным выполнением задач:

• 5 элементов BPMN: Start Event → User Task → Service Task → Service Task → End Event
• 2 эксклюзивных шлюза для обработки результатов проверки
• 3 внешних задачи (external tasks) на экземпляр процесса

Процесс моделирует упрощённый бизнес-сценарий с базовыми этапами: поиск компании получателя платежа, выполнение анти-фрод проверки, и финальная проверка получателя с возможностью отмены или одобрения операции.

2.3. Критерии успешности

Основным критерием успешности прохождения ступени нагрузки являлось поддержание доли успешно завершенных экземпляров процессов на уровне не менее 85% от числа стартовавших. Тест считался завершенным, и его результатом признавалась последняя полностью пройденная ступень, как только на очередной ступени данный показатель опускался ниже порогового значения.

2.4. Конфигурация инфраструктуры

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

Стенд Camunda 7:

• Узел Camunda 7: 1 шт. (4 vCPU, 8 ГБ RAM)
• Узлы External Task: 2 шт. (4 vCPU, 8 ГБ RAM каждый)
• Узел Postgres 16: 1 шт. (8 vCPU, 32 ГБ RAM)
• Итого: 20 vCPU, 56 ГБ RAM.

Стенд Платформа 7:

• Узел Платформа: 1 шт. (4 vCPU, 8 ГБ RAM)
• Узлы External Task: 2 шт. (4 vCPU, 8 ГБ RAM каждый)
• Узел Postgres 16: 1 шт. (8 vCPU, 32 ГБ RAM)
• Дополнительно: Узел Kafka: 1 шт. (4 vCPU, 4 ГБ RAM)
• Итого: 22 vCPU, 60 ГБ RAM.

3. Анализ пиковой пропускной способности и стабильности системы

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

3.1. Производительность Платформы 7

Система на базе Платформа 7 успешно справлялась с нагрузкой вплоть до ступени 150 PPS включительно. На следующей ступени, при подаче нагрузки в 160 PPS, было зафиксировано падение соотношения завершенных процессов к стартовавшим ниже критической отметки в 85%. В соответствии с методологией, максимальная стабильная производительность была зафиксирована на уровне 150 PPS.

3.2. Производительность Camunda 7

Эталонная система Camunda 7 начала демонстрировать признаки деградации уже на ступени в 140 PPS. На этом уровне нагрузки соотношение completed/started опустилось ниже 85%, что привело к завершению теста. Таким образом, максимальная стабильная производительность для стандартной архитектуры составила 140 PPS.

3.3. Визуальный анализ деградации производительности

Ключевое различие в поведении систем проявляется при выходе за пределы стабильной работы.

• Ключевой график для вставки: Сравнительный график completed/started (%) для обеих платформ.
• Интерпретация: Графики показывают, что при достижении нагрузки в 140 PPS система Camunda 7 испытывает резкий сбой: доля успешно завершенных процессов лавинообразно падает. Это говорит о том, что система достигла жесткого предела, за которым следует быстрая деградация. В то же время Платформа, даже на нагрузке в 160 PPS (превышающей ее стабильный предел), демонстрирует гораздо более плавное снижение показателя успешности. Система не “обваливается”, а продолжает обрабатывать значительную часть потока, что дает больше времени на реакцию и свидетельствует о большем запасе прочности архитектуры.

4. Анализ нагрузки на базу данных и выявление узких мест

Данный раздел является центральным в исследовании, поскольку он напрямую анализирует эффект от переноса записи истории из БД в Kafka.

4.1. Нагрузка на запись и буферы БД

• Наблюдение: Анализ метрик буферов PostgreSQL, в частности Buffers (bgwriter), показывает кардинальные различия. Для Camunda 7 количество буферов, записываемых на диск фоновым процессом (buffers_checkpoint) и бэкендами (buffers_backend), на порядки выше, чем для Платформы 7.
• Интерпретация: Эта метрика напрямую отражает интенсивность операций записи на диск. В PostgreSQL фоновый процесс (background writer) и чекпоинты отвечают за сброс измененных данных (“грязных” буферов) из оперативной памяти на диск. Высокие значения для Camunda 7 свидетельствуют о колоссальном объеме записи, генерируемом историческими таблицами. База данных вынуждена постоянно освобождать место в буферном кэше, сбрасывая данные на диск. В Платформе 7, где история уходит в Kafka, нагрузка на запись минимальна. Это позволяет СУБД эффективно использовать кэш и избегать интенсивных дисковых операций, что и является одним из ключевых факторов повышения общей производительности и стабильности.

Camunda 7:

Платформа 7:

4.2. Интенсивность операций записи

• Наблюдение: По данной метрике наблюдалась наиболее драматическая разница. Показатель для Camunda 7 был на порядки выше, чем для Платформы.
• Интерпретация: Эта метрика, отражающая количество обновленных строк в базе данных в секунду (на основе системного счетчика PostgreSQL pg_stat_database_tup_updated), напрямую показывает нагрузку на диски, связанную с записью истории. Перенаправление этих событий в Kafka практически полностью устраняет данный вид нагрузки на основную БД в Платформе. Именно эта интенсивная и непрерывная запись является первопричиной деградации производительности Camunda 7.
• Ключевой график для вставки: Графики Update data для обеих платформ. (См. Image 3 и Image 7, график “Update data”).

Camunda 7:

Платформа 7:

4.3. Конкуренция за ресурсы и блокировки

• Наблюдение: В тесте Camunda 7 наблюдалось большее количество активных сессий и более частые блокировки таблиц.
• Интерпретация: Высокий объем операций записи в Camunda 7 неизбежно приводит к тому, что разные части системы начинают “бороться” за доступ к базе данных. Это создает эффект “снежного кома”: замедление одних операций приводит к исчерпанию свободных подключений к БД и дальнейшему замедлению всей системы. Короткие транзакции в Платформе минимизируют это соперничество, что обеспечивает более отзывчивую и стабильную работу базы данных.

Camunda 7:

Платформа 7:

5. Анализ утилизации системных ресурсов

5.1. Потребление ресурсов сервером PostgreSQL

• Наблюдение: Нагрузка на процессор (CPU) сервера базы данных в тесте Платформы 7 была существенно ниже, чем в тесте Camunda 7.
• Интерпретация: Операции записи - крайне ресурсоемкая задача. Устранив подавляющую часть этих операций, архитектура Платформы значительно снизила нагрузку на сервер базы данных.

Camunda 7:

Платформа 7:

5.2. Потребление ресурсов сервером приложения

• Наблюдение: Нагрузка на CPU сервера приложения Платформы 7 была несколько выше , чем на сервере Camunda 7 при одинаковой нагрузке.
• Интерпретация: Этот, на первый взгляд, парадоксальный результат является признаком более здоровой работы системы. В случае с Camunda 7, приложение часто простаивает, ожидая ответа от перегруженной базы данных. В это время оно не потребляет ресурсы CPU. В Платформе приложение не ждет и постоянно занято полезной работой: обработкой логики процесса и отправкой данных в Kafka. Эта более высокая “плотность работы” и приводит к росту утилизации CPU.

Camunda 7:

Платформа 7:

6. Заключение и архитектурные рекомендации

Результаты нагрузочного тестирования подтверждают, что вынос механизма записи истории в Apache Kafka является эффективной стратегией для повышения производительности системы. Данный подход напрямую устраняет узкое место, связанное с интенсивной записью в базу данных при уровне историчности full.

В ходе тестов Платформа 7 продемонстрировала способность обрабатывать стабильную нагрузку в 150 процессов в секунду (PPS), что на 7% выше показателя стандартной конфигурации Camunda 7 (140 PPS). Ключевым результатом является не только рост пиковой производительности, но и значительное снижение нагрузки на СУБД PostgreSQL. Это выражается в уменьшении количества транзакций, обновлений строк и, как следствие, снижении утилизации CPU на сервере базы данных. Такое изменение архитектуры обеспечивает более стабильную работу системы под нагрузкой, с более плавной деградацией производительности при выходе за пределы штатного режима.