CPU and RAM
DCV Gateway
The CPU and RAM usage are directly affected by which protocol you are running (WS/TCP, QUIC/UDP or a mix).
QUIC/UDP consume more resources because it implements congestion control, reliability, and encryption at the application layer (userspace) rather than relying on the kernel’s TCP stack. TCP/WebSocket can offload some operations to hardware and benefits from decades of kernel optimizations
Ideally you need to monitor your Gateway and the user experience to find the best number for your use case, but as a start point:
- 300 concurrent WS/TCP connections: 6 dedicated CPU cores, 16GB RAM
- 300 concurrent QUIC/UDP connections: 8 dedicated CPU cores, 16GB RAM
The real usage depend of your CPU features, of your RAM capacity (latency, bandwidth etc) and of course the kinf of traffic generated by every user. Our requirement recommendation does not expect to fully use the CPU and RAM when it reaches 300 users
DCV Session Manager
- For the Broker you can provide 2 CPU cores with 8GB RAM.
- For the Agent, as it execute in the same DCV Server, you just need to gurantee 4GB available to the agent.
Bandwidth
DCV Gateway
This is something that is very affected by the user context usage. As DCV Server is very efficient to update the DCV Viewer, the usage can go from a small amount of kbytes/s to up to a hundred of mbytes/s peaks, when needed. You have to monitor your DCV traffic to understand your bandwidth average usage.
DCV Session Manager
The Session Manager does not produce too much traffic. You need to guarantee enough network quality to avoid network interruptions by firewall or misconfiured routes, which will prevent the correct comunication between Session Manager components.
Load Balance
DCV Gateway
As a good start point, we recommend to have up to 300 concurrent users in every DCV Gateway. It does not mean that after that it will start to affect the users experience. In general this is a good number to avoid filling the memory and CPU bus, stay away from default file descriptors limits and possible big CPU lenght queue. Also, seems to be a good idea to divide the users into multiple DCV Gateway to not depende exclusively of just one server (where DCV Gateway is installed).
File descriptors
DCV Gateway
Every DCV connection (on top of WebSocket transport) opens about 6 underlying TCP connections. Thus, each DCV connection handled by the DCV-gateway needs ~6 x 2 socket descriptors (as the gateway has keep connectivity on 2 sides: towards the dcv client and the dcv server). So, for WS/TCP you can expect up to 12 file descriptors per connection. You need to check your Linux limits to support that.
Disk usage
DCV Gateway
There are no special requirements for space needed, unless you need to store a long period of DCV Gateway metrics and set DEBUG log level to troubleshooting something, you can start with 10GB dedicated to DCV Gateway logs.
