Thanks kukeltje, I've read that blog about performance before as well as your jbpmplanet blog too. As for "tuning-jbpm-in-cluster.html" the point there is demonstration of jBPM scalalability rather than performance i guess. For me it's not clear whether workflow under the test is complex or a simple one (as one i'm using), because for 2000 "escalations" (is it jBPM terminology?) even the best time of 34 secs doesn't look great. But "tuning-jbpm-in-cluster.html" also mentions that number of threads which execute process can be increased - may be that's the way i could achieve better performance in my case? Another question is there only one way to run the same process multiple times: Execution execution = executionService.startProcessInstanceByKey("NoOperation"); , or may be other approaches exist which would allow better performance, considering more constraints of course. If you ask me - 3 millisecs per process isn't very good result - don't blame me, but i've tried Drools Flow with similar NoOperation flow where only start and end present. The results i got were - [0.5 ... 10,5] secs depending on the how the sessions are treated. I understand that the process state in jBPM is persisted and it will always have impact on the performance. May be it's not a correct question but is it possible to disable process state persistency, so DB won't be involved at all?? As i said am just making evalution and try to choose the right technology for "workflow" engine which could face our near real-time requirements. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4237248#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...