- Release Notes
- Installation and upgrade
- Before you begin
- Getting started
- Activities
- Designing long-running workflows
- Start Job And Get Reference
- Wait For Job And Resume
- Add Queue Item And Get Reference
- Wait For Queue Item And Resume
- Wait For Form Task And Resume
- Resume After Delay
- Assign Tasks
- Create External Task
- Wait For External Task And Resume
- Complete Task
- Forward Task
- Get Form Tasks
- Get Task Data
- Get App Tasks
- Add Task Comment
- Update Task Labels
- Configure task timer
- Actions
- Processes
- Audit
Action Center
- Single node deployments - single node Action Center connected to a single node Orchestrator instance
- Multi-node deployments - we recommend the following multi-node deployments:
- In a multi-node deployment scenario, the Orchestrator is set up behind a load balancer, while a single instance of Action Center is installed on a separate server. Action Center is configured to point to the URL of the Orchestrator's Load Balancer.
- Another type of multi-node deployment involves setting up the Orchestrator behind a load balancer with multiple nodes. In this configuration, Action Center is installed on each Orchestrator node, and each instance of Action Center points to the Orchestrator's Load Balancer URL.
Single-node hardware requirements
|
Max. Concurrent Users |
CPU Cores (min 2GHz) |
RAM (GB) |
|---|---|---|
|
4,000 |
2 |
4 |
|
12,000 |
4 |
4 |
Test Setup and Sample Data
To test the performance for a single node Action Center connected to a single node Orchestrator instance, the below setup and sample data was used:
- 3 hours of test time
- Form Data payload having a size of 5000 bytes
- 28,000 actions created
- 17 different API endpoints executions
- Simulated concurrent users
Multi-node hardware requirements
Based on our performance tests, we recommend the maximum numbers below:
- 150,000 attended robots connected to Orchestrator and running jobs
- 10,000 Action Center users processing actions
- 3,000 unattended robots running jobs (creating actions and resuming after the actions completion)
Environment Configuration
To ensure seamless performance for the above scenario, we recommend setting the environment below.|
Instance |
No. of Deployment Nodes |
Azure VM |
vCPU Cores |
Frequency (GHz) |
RAM (GB) |
|---|---|---|---|---|---|
|
Action Center |
3 |
B2s |
2 |
2.0 |
4 |
|
Orchestrator |
10 |
F16 |
16 |
2.0 |
32 |
|
SQL Server |
1 |
F32 |
32 |
2.0 |
64 |
Drive Storage
Allocate a drive for each of the following content:
|
Stored Content |
Drive Capacity |
|---|---|
|
Database |
1TB |
|
Temporary database |
1TB |
|
Transactional logs |
1TB |
Database Setup
|
Product |
Configuration |
|---|---|
|
Redis Enterprise HA |
CentOS 8 CPU Cores 2.0 GHz minimum frequency 16GB RAM |
|
Bucket storage VM |
Standard L32s_v2 Ultra Disc 4TB 900MB/s throughput |
Test Setup and Sample Data
We generated the hardware requirements, along with additional setups and configurations, by conducting performance tests that simulate a large load on Action Center and Orchestrator. The tests were performed using the following sample data:
- 10,000 concurrent Action Center users
- 240,000 actions
- 60% document validation actions
- 40% form actions
- Payload per one form action:
- Form layout—5KB
- Form data—5KB
- 10 storage files x 100KB
- Payload per one document validation action:
- One PDF file x 150KB
