uhhmmm... that is 0.0033 seconds per process.... Do not compare this to a java for loop... 0.0033 seconds with lots of database access. That is over 100.000 processes per hour. Is that bad?
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.
Not sure how to configure those if it is possible at all in the initial 4.0 release. Might be that some other modes will become available in 4.0.x or 4.1
And yes, multiple threads is indeed an option. In the performance tuning article the jbpm 'client' (your application) can start multiple parallel request e.g. via webpages. If you need some kind of batch processing, use e.g. jms to do parallel things with one simple mdb on a queue that starts one process if something is put in the queue and have x mdb's then
The reason the article talks about increasing the threads is because async jbpm functionality in the background. If you start many processes, but only have one thread executing jobs (e.g. timers) a huge bottleneck is introduced there.
Thank you again!
The in-memory execution mode - is what i will be looking for in jBPM ))
Howere, jBPM roadmap says nothing about different execution modes.
Different execution modes is something that will be worked out in one of the next versiosn (ie 4.x). Do note that the use cases for business procecess with no persistency are extremely limited. You're talking more about modeling algortihms then instead of business processes, where generally one thinks in minutes, hours, days or even months. In-memory execution is not an option in these cases.
I did a performance test of jBPM3 in the past:
As you can see, even with persistency jBPM3 was fast imo. Do note that 4.0 is a first release, where stability and use case coverage is the goal. Performance will certainly be tackled in the coming months.
ok, now i see that i haven't searched enough through the forum ))
There are more performance test reports as you mentioned, jbarrez.
The performance numbers reported there are different :
Actually, the performance numbers from 2) look similar to what i got so far (~3ms). But i run my test on a laptop without any changes in hibernation configuration.
So there is still a place for optimization - adding more executor threads and changing hibernation configuration.
Adding more executor threads will only help when there is a bottleneck in the asynchronous continuations, not in regular business process execution.
But tweaking Hibernate for your needs is generally an excellent idea.