Use the following article to properly size the required ControlUp components that monitor your environment. Whether your organization is small or large, ControlUp offers scalability. To ensure high availability, we recommend that your monitor cluster/sites and the data collectors be redundant with N+1.
You can use our interactive online sizing calculator here. This allows you to input the exact details of your environment and calculate the recommended number of ControlUp onitor nodes. If you require assistance with sizing, contact our Support Team at support@controlup.com.
The scalability limit of a single monitor node is 320,000 concurrent processes. The actual limit of VDI machines per monitor node depends on the average number of concurrent processes per VDI machine.
For a customer with an avg. of 200 concurrent processes per machine, a single monitor node supports 2,000 VDI machines.
VDI-based workloads
The sizing recommendations below are based on typical VDI environments, including Windows 10 or Windows 11 virtual machines, with or without third-party software such as Citrix Virtual Apps and Desktops, Omnissa Horizon (formerly VMware Horizon), or Microsoft AVD.
The primary sizing factor is the number of VDI machines connected to ControlUp. If your environment manages more than 500 VDI machines, you must disable the process flat views in the Real-Time DX Console to maintain performance.
ControlUp Monitor and Console hardware sizing
ControlUp Monitor and Real-Time DX Console hardware sizing is shown in the table below. A higher number of vCPUs and RAM means better performance.
| ControlUp Component | Monitor Node(*) | Console(***) | ||||
| VDI Workloads | 2,000 | 3,000 - 4,000 | 4,000(****) | 0 - 1,000 | 1,000 - 2,000 | 2,000 - 4,000 |
| vCPU(**) | 4 | 8 | 8 | 2 | 2 | 2 |
| RAM | 16 | 24 | 32 | 4 | 6 | 8 |
(*) Additional monitor nodes should be deployed in environments with more than 2,000 VDI machines. You can find examples for configurations consisting of 500, 5,000, 20,000, and 50,000 VDI machines below.
(**) 2.8Ghz clock speed or higher.
(***) Per console instance, based on a fully optimized console, see here.
(****) A monitor node can support up to 320,000 concurrent processes, so the maximum number of VDI machines per monitor node is determined by the average number of concurrent processes per VDI machine.
One monitor node supports 2,000 VDI machines for a customer with an average of 200 concurrent processes per machine. A properly sized monitor node can handle dozens of triggers per minute.
VDI sizing examples
These examples are based on an average of 200 concurrent processes per VDI machine and on an N+1 redundancy configuration.
| Example configuration for 500 VDI machines | ||||
| ControlUp Component | # of VM's / Instances | vCPU (per instance) | RAM(per instance) | Notes |
| Monitor Nodes(*) | 2 | 4 | 16 | N+1 configuration |
| Real-Time Console | N/A | 2 | 8 | Per console instance |
| Data Collector | See Data Collectors. | |||
| Example configuration for 5,000 VDI machines | ||||
| ControlUp Component | # of VM's / Instances | vCPU (per instance) | RAM (per instance) | Notes |
| Monitor Nodes(*) | 5 | 8 | 32 | N+1 configuration |
| Real-Time Console | N/A | 2 | 8 | Per console instance |
| Data Collector | See Data Collectors. | |||
| Example configuration for 20,000 VDI machines | ||||
| ControlUp Component | # of Instances | vCPU (per instance) | RAM (per instance) | Notes |
| Monitor Nodes(*) | 16 | 8 | 32 | N+1 configuration, additional 2 Management Monitors will be required with : 4 vCPU & 8 GB RAM |
| Real-Time Console | N/A | 2 | 8 | Per console instance |
| Data Collector | See Data Collectors. | |||
| Example configuration for 50,000 VDI machines | ||||
| ControlUp Component | # of Instances | vCPU (per instance) | RAM (per instance) | Notes |
| Monitor Nodes(*) | 35 | 8 | 32 | N+1 configuration, additional 2 Management Monitors will be required with : 4 vCPU & 16 GB RAM |
| Real-Time Console | N/A | 2 | 8 | Per console instance |
| Data Collector | See Data Collectors. | |||
RDSH-based workloads The sizing numbers below are based on environments where the end users are running on RDSH-based servers. The main factor is the number of concurrent sessions being managed using ControlUp. Note that if you manage more than 2,000 concurrent user sessions, it is a mandatory requirement to disable the process flat views in the Real-Time Console.
| ControlUp Component | ControlUp Monitor Node | ControlUp Real-Time Console(**) | ||
| RDS Sessions | 0 - 5,000 | 5,000 - 10,000(***) | 0 - 5,000 | 5,000 - 10,000 |
| vCPU(*) | 4 | 8 | 2 | 2 |
| RAM | 16 | 32 | 8 | 8 |
(*) 2.8Ghz clock speed or higher.
(**) Per console instance, based on a fully optimized console, see this article.
(***) Based on approximately. 20 processes per RDS session.
For further information regarding Data Collectors, see here.
RDSH sizing examples
The scalability limit of a single monitor node is 320,000 concurrent processes, so the actual limit of RDS hosts per monitor node depends on the average number of concurrent processes per host including the host. On average, a single monitor node supports 10,000 concurrent sessions.
The numbers below vary between organizations due to the number of sessions running on each host. These examples are based on an average of 200 concurrent processes per an RDSH, and 20 processes per session on an N+1 configuration.
| Example Configuration for 5,000 RDS Sessions Running on 250 RDSHs | ||||
| ControlUp Component | # of Instances | vCPU (per instance) | RAM (per instance) | Notes |
| Monitor Nodes(*) | 2 | 4 | 16 | N+1 configuration |
| Real-Time Console | N/A | 2 | 8 | Per console instance |
| Data Collector | See Data Collectors. | |||
| Example Configuration for 20,000 RDS Sessions Running on 1,000 RDSHs | ||||
| ControlUp Component | # of Instances | vCPU (per instance) | RAM (per instance) | Notes |
| Monitor Nodes(*) | 3 | 8 | 32 | N+1 configuration |
| Real-Time Console | N/A | 2 | 8 | Per console instance |
| Data Collector | See Data Collectors. | |||
| Example Configuration for 50,000 RDS Sessions Running on 2,500 RDSHs | ||||
| ControlUp Component | # of Instances | vCPU (per instance) | RAM (per instance) | Notes |
| Monitor Nodes(*) | 5 | 8 | 32 | N+1 configuration |
| Real-Time Console | N/A | 2 | 8 | Per console instance |
| Data Collector | See Data Collectors. | |||
Data Collectors
We always recommend that you configure dedicated data collectors for hypervisors, EUC connections, and NetScalers. In large environments, you should run the data collector on a dedicated VM. For more details about why a data collector is important both for your environment and the performance of the Real-Time Console, see here.
Properly sizing how many data collectors to connect depends on which type of data source you're assigning to the data collector:
- Hypervisors (Omnissa/VMware, Hyper-V, XenServer, Nutanix): Data collectors query hosts, machines, datastores, and virtual disks. Adding vCenter in particular can use more RAM based on the number of machine records retrieved via the vSphere API.
- EUC environments (Citrix Virtual Apps and Desktops, Omnissa Horizon): Data collectors query topology (delivery groups/desktop pools), brokers/connection servers, machines, and sessions. Citrix sites use more CPU due to the PowerShell API queries involved.
- NetScaler: Data collectors query appliance info and metrics, load balancers, HDX sessions, and gateways. This uses more network bandwidth due to the volume of data retrieved via the Nitro API.
Recommended Data Collector VM sizing: 4 vCPU / 8 GB RAM per data collector instance.
How Many Data Collectors Do You Need?
As a general rule of thumb:
- Deploy one dedicated Data Collector per data source type (e.g., one for your hypervisor layer, one for your EUC/Citrix or Horizon layer, one for NetScaler) rather than combining unrelated data source types on a single data collector. This keeps resource usage predictable and isolates the impact of any one data source (e.g., API throttling on Citrix Cloud) from the others.
- For high availability, configure data collectors with N+1 redundancy. This is the same principle applied to ControlUp Monitor nodes elsewhere in this article, so that if one data collector goes offline, monitoring continues uninterrupted.
- In large-scale environments (multiple vCenter instances, large Citrite sites, or multiple NetScaler pairs), you might need to scale out to multiple data collectors per data source type as record counts grow. For example, splitting vCenter Data Collectors across regions or datacenters to reduce per-instance load and latency.
- If you're unsure how many data collectors your specific environment needs, use the ControlUp Sizing Calculator, or contact our Support Team at support@controlup.com for a sizing review based on your exact data source counts.