In a single node test for a non-trivial process, i saw the following numbers.
These are with default configuration. I have not tried to optimize or tune anything
Scenario - Create process instance with 4 custom POJOs, one containing a list (usually its best to have not more than 1 or 2 lightweight pojos)
Tomcat/SqlServer
5 threads - 596/minute
10 threads - 936/minute
50 threads - 613/minute (server maxed out)
Was/Sqlserver
5 thread - 1359/minute
10 thread - 1701/minute
50 thread - 446/minute (server did not max out)
No exceptions in either case
Scenario - Claim task (display 25 tasks/page; each thread claims a random task on page)
Logic -
get 25 tasks on a page
processConfig.getTaskService().createTaskQuery().processDefinitionKey(PROCESS_KEY).taskUnnassigned().listPage(0,25);
select a task on page at random
processConfig.getTaskService().claim(task.getId(), user.getId());
Tomcat/SqlServer
5 threads - 521/minute
10 threads - 720/minute
50 threads - 394/minute
WAS/SqlServer
5 threads - 202/minute
10 threads - 241/minute
50 threads - 181/minute
# of exceptions were approx 10%, 20% and 50% respectively in both cases, all related to threads concurrently claiming the same task. That has more to do with process design than activiti itself
The only 'issue' was about timers/jobs. if there were a several process instances and timers are required, it took a while to trigger escalations. I had a task escalated if noone worked on it for 15 minutes
In a multi node environment, some other posts had said to run the jobexecutor on only one node, so that may be a constraint
