Production performance tuning

[bwd]

We're planning production resources and are wondering if there are any sizing/tuning guidelines specifically for Activiti. 

I'm guessing that the guidelines for things like database connection and thread pool sizes for the app server it's running in are pretty standard (basically, at least one thread and connection per required concurrent execution), but what about tuning settings for things like the internal job execution thread for timers, …, etc?

Any estimates on the memory footprint for a process engine and process instances?  Is memory usage growth tied to any run time activity that we can use to estimate memory requirements.

I do see some indexes on the database tables, which I assume cover the most frequent/expensive queries.  Our usage is performing queries for processes and tasks based on variables set on the workflow processes.  Should we be adding indexes to make these queries efficient as the data set size grows (if that's not already covered)?

Thanks in advance for any guidance.

BD

[ronald_van_kuij]

Your analysis is good.

The jobexecutor might need tuning to but check if it is a bottleneck first since afaik configuring it not exposed (yet?) in the config (see) modules/activiti-engine/src/main/java/org/activiti/engine/impl/cfg/ProcessEngineConfigurationImpl.java but harcoded in modules/activiti-engine/src/main/java/org/activiti/engine/impl/jobexecutor/JobExecutor.java

The engine itself has a low fairly low footprint, so I'd not care about that. Each process instances that is in a waitstate (usertask, receivetask etc) does not occupy any memory. A process instance only occupies memory if it is actually loaded from the db because it has to 'run'. How much is dependend on e.g. variables loaded etc, but it is not high either.

Adding indexes should indeed be done according to your needs since the default engine cannot cater for all usecases. A query analyzer helps a lot here.
Adding to many howeve can lead to performance degradation since the index has to be updated each time a record is added but I suspect you already know that.

[jkronegg]

From my experiments:

• Each ProcessEngine has a memory footprint of about 4 MB.
• The deployed processes do not use memory since they are stored in the database. However, they are cached into ProcessEngineConfigurationImpl.getProcessDefinitionCache() which is basically a HashMap so if you deploy thousands of processes, your memory footprint will rise. If you deploy a lot of processes, you should use a smarter process definition cache, e.g. one based on soft references so that the cache is garbage collected when the memory is low.