topic Re: Time usage of the activiti engine while execute endevent in Alfresco Archive

Time usage of the activiti engine while execute endevent

markno — Thu, 03 Nov 2011 15:32:34 GMT

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 Ser

Re: Time usage of the activiti engine while execute endevent

ronald_van_kuij — Thu, 03 Nov 2011 17:35:38 GMT

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'

Re: Time usage of the activiti engine while execute endevent

markno — Fri, 04 Nov 2011 08:10:05 GMT

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.

Re: Time usage of the activiti engine while execute endevent

ronald_van_kuij — Fri, 04 Nov 2011 08:41:47 GMT

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.