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.
