I just ran a test on the sample (reference) web application provided by the jbpm-starters-kit-3.1.1.
The test was to create an order using 'Cookie monster' login, later I traced the generated SQL statements.
What I founds was around 40+ insert statements for the following JBPM tables JBPM_VARIABLEINSTANCE, JBPM_TOKENVARIABLEMAP, JBPM_SWIMLANEINSTANCE, JBPM_TIMER, JBPM_TASKINSTANCE, JBPM_LOG, JBPM_MODULEINSTANCE
I am wondering did I miss something or is this the expected behavior? It is very expensive for my application, which is more complex than the sample application provided JBPM to handle 40+ insert statement + another set of update statements for each of the major transaction of the system.
Can you please clarify this? Is there a way I can optimise this?
there is a lot of room for optimisation. so far we focussed on getting it running out of the box on as many environments as possible.
now we will be focussing on optimizing a bit and documenting in a wiki page to describe what the typical performance optimisation options are and what the tradeoff is.
I disabled the logging it reduced significantly the number of insert statements (cuz now it is not inserting inside jbpm_log table) but still around 40+ insert and update statements.
I am wondering whether any one is using this product in production and how is the performance for typical application with around hundred thousand records?
How did you disable the logging? I'm trying to do the same.
You can try commenting the following line inside jbpm.cfg.xml:
<service name="logging" factory="org.jbpm.logging.db.DbLoggingServiceFactory" />
Let me know if this doesn't work for you.
Btw, are you using this in production and how is your performance?
I didn't really try running any profilers or something yet to determine the performance issues but would appreciate hearing from other folks.