Scalability

Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-21-2011 02:30 AM
Dear Communitity
We are planning to use activiti for a system which processes a couple of million orders per year, thus there will be quite a lot process instances running simultaniousely. Are there any case studies or something like that which show that activiti is able to handle such loads? Is anybody aware of any scalability issues?
Thanks a lot in advance for your feedback
Christoph
We are planning to use activiti for a system which processes a couple of million orders per year, thus there will be quite a lot process instances running simultaniousely. Are there any case studies or something like that which show that activiti is able to handle such loads? Is anybody aware of any scalability issues?
Thanks a lot in advance for your feedback
Christoph
Labels:
- Labels:
-
Archive
1 REPLY 1
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-28-2011 01:54 PM
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
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
