Time usage of the activiti engine while execute endevent

[markno]

Hello community,

We develop short time server processes and think about to use activiti for modelling the process and execute it within the engine. It is fundamental for our project to be fast and save server performance.
While evaluate a scenario with 3 Service Tasks and one sub process with one Service Task we recognize that the engine will take a lot of the execution time while handle the endevents. Can someone explain please what the engine does after finishing the last service task? Can we optimize this behaviour?

The measure data shows an execution time of all service task of only 1-2ms. After execution of the last service task up to the return of the activiti-engine it will cost 40-60ms.

Best Regards,
Markus

[ronald_van_kuij]

it really depends on how your process looks like. If there are no waitstates, all db persistency is done at the end and you can see a big 'difference'

[markno]

Activiti should be used in our environment to conenct components (Java Beans) to a process. At the moment we build inflexible connections inside the beans with coded lookups. This is very fast.
Our idea is to make this flexible by describe the connections with activiti. In the test scenario we have only plain beans with simple logic (calculate some values) and make system.outs with current time. We want to evaluate the time deficite by using a BPMN engine. The scenario has no waitstate, only startevent, service tasks (the execution of the beans) and an end event. The example shows a possible process in out real environment. The SubProcess is simple an StartEvent, ServiceTask and EndEvent.

Activiti will be do all internal db persistency at the end of the process (after an EndEvent)? It is possible to optimize this behavior? If not, we will further use the hard coded connection, because we have the main requirement to be fast.

[ronald_van_kuij]

Activiti will be do all internal db persistency at the end of the process (after an EndEvent)? It is possible to optimize this behavior? If not, we will further use the hard coded connection, because we have the main requirement to be fast.

You could try playing with the history level.

But if you needs some kind of persistency, then hardcoding will also result in db acces and slowing things down. Moving persistency to other steps in the process (e.g. by using the async functionality) only moves it, not speeds it up. If you do not need real persistency, you could use an in memory db and clean records up after an instance finishes.