JPBM - часть 6 - производительность.

После пяти статей про JBPM самое время написать про основную фобию разработчиков перед такого рода движками - ПРОИЗВОДИТЕЛЬНОСТЬ. Именно это магическое слово я слышу каждый раз когда речь заходит о workflow или process management продуктах. Одной статьей развеять эту убежденность не получится, но я все же попробую начать.

Я провел несколько тестов. В чем они заключались? На входе имеем сервлет, обрабатывающий запросы следующим образом: на основе входных параметров(v1, v2, v3), создается объект и передается в экземпляр процесса, который после этого запускается. Использовался типовой процесс бизнес-приложения(25 нодов, в среднем 10 переходов). Сервер приложений jboss-5.0.1.GA . Для тестирования использовался Jmeter. Тест состоит из трех ThreadGroup, каждая из которых содержит 100 пользователей, посылающих запросы в систему.

Тестирование отклика системы.
Проверялось сколько запросов система готова обработать за единицу времени. Рассматривались два случая: асинхронное и синхронное исполнение процесса со стороны JBPM. В первом случае сервлет заканчивал обработку запроса запуском процесса, после чего последний выполнялся в отдельной нитке. Во втором варианте сервлет ожидает окончания исполнения процесса и только после этого заканчивает обработку входящего запроса.

Синхронное исполнение


Из таблицы видим, что в этом случае обрабатывается 10.1 запроса в секунду. Максимальное время исполнения процесса 3 секунды, минимальное 10мс. 90% запросов исполняются за время < 1с.

Асинхронное исполнение

Видим, что разница в 9.5 раз по скорости, имеем 95.2 запросов в секунду. Максимальное время исполнения процесса в данном случае - 30 секунд. Минимальное -
100мс. 80% запросов исполняются за время < 1 c.

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