Hi,
we made some performance tests with Activiti on a hardware with 12 cores (tomcat server with Activiti + separate database server).
During these tests we observed a contention in MyBatis' dynamic query creation mechanism which is called from ExecutionEntity.remove() for every finished process instance.
The dynamic queries are created by: TaskQueryImpl(commandContext).executionId(id).list() and JobQueryImpl(commandContext).executionId(id).list(), see below:
As an example the statement for selecting the jobs belonging to a process instance (from our changed /org/activiti/db/mapping/entity/Job.xml😞
Some more details concerning our tests:
The test scenario was a multi-threaded test client that started process instances and waited for their completion, measuring the throughput: how many processes completed in a given time (e.g. per minute).
The test process had the following features:
) alternatives that we may have overlooked.
we made some performance tests with Activiti on a hardware with 12 cores (tomcat server with Activiti + separate database server).
During these tests we observed a contention in MyBatis' dynamic query creation mechanism which is called from ExecutionEntity.remove() for every finished process instance.
The dynamic queries are created by: TaskQueryImpl(commandContext).executionId(id).list() and JobQueryImpl(commandContext).executionId(id).list(), see below:
… CommandContext commandContext = Context.getCommandContext(); List<TaskEntity> tasks = (List) new TaskQueryImpl(commandContext) .executionId(id) .list(); for (TaskEntity task : tasks) { if (replacedBy!=null) { task.setExecution(replacedBy); } else { commandContext .getTaskManager() .deleteTask(task, TaskEntity.DELETE_REASON_DELETED, false); } } List<Job> jobs = new JobQueryImpl(commandContext) .executionId(id) .list(); for (Job job: jobs) { if (replacedBy!=null) { ((JobEntity)job).setExecution((ExecutionEntity) replacedBy); } else { ((JobEntity)job).delete(); } } …As an example the statement for selecting the jobs belonging to a process instance (from our changed /org/activiti/db/mapping/entity/Job.xml😞
<select id="selectJobsByExecutionId" parameterType="string" resultMap="jobResultMap"> select * from ACT_RU_JOB J where J.EXECUTION_ID_ = #{executionId} </select>Profiler shows that they consume at least 50-70% of overall time.We created a Jira issue (ACT-1056) and can contribute a patch if needed.
Some more details concerning our tests:
The test scenario was a multi-threaded test client that started process instances and waited for their completion, measuring the throughput: how many processes completed in a given time (e.g. per minute).
The test process had the following features:
- main process:
- two ServiceTasks performing db updates (each with asynchronous continiuation)
- two ServiceTasks sending jms notifications back to the test client
- call of a sub process (with asynchronous continiuation)
- sub process
- two ServiceTasks that call WebServices (SoapUI simulator was used for these WebServices)
- two exclusive gateways
) alternatives that we may have overlooked.
