Performance Optimizations in IGEL UMS
Data Sizing
- The number of registered firmware versions has the largest impact on the size of the database.
(Listed in UMS Console under Misc > Firmware Statistics) - The number of devices or profiles has a minor impact.
- Average size per...
- Firmware configuration: ~15 MB
- Profile (depends on the number of active parameters): ~100 kB
- Device: ~100 kB
- Reserve 500 MB up to 1 GB for database transaction logs of excessive database calls like Remove unused Firmware. Please note that the usage depends on the database system used.
Latencies
If you are struggling with long-distance connections and high latency, please consider the following recommendations:
- Minimize latency between...
- Database <-> UMS Server: <= 20 ms
- Several UMS Servers: <= 50 ms
- Load balancer <-> UMS Server: <= 50 ms
- High latency between the database and the UMS Server has a huge impact on the performance. The communication between the device and the UMS Console will slow down, the UMS Console itself will become lazy.
- High latency between the device and the UMS Server has little impact on overall performance.
Performance Optimizations
- UMS logs:
Use administrative tasks to automatically clean up logs (logging data, job execution data, execution data of administrative tasks, process events, asset information history) or remove old UMS log files (/rmguiserver/logs
) when storage space runs out. - Firmware:
Remove unused firmware regularly. - Embedded database only:
- Optimize database regularly (UMS Administrator application, e.g. once a month)
- Check for free storage space and expand the storage size if necessary (keep at least 1 GB free at all times)
- Number of devices:
- If the device count is high (>10k) and overall performance is low, increase UMS Server and UMS Console memory. See How to Configure Java Heap Size for the UMS Server and How to Configure Java Heap Size for the UMS Console.
- Avoid too many devices (>5k) in one folder.
- Assignments:
Keep the number of assignments per device (direct and indirect) at a low level (<25). - Administrative tasks and jobs:
The more administrative tasks and jobs are created, the more heap is "eaten up", so it may be necessary to increase UMS Server memory. See How to Configure Java Heap Size for the UMS Server. - Default directory rules:
Do not use default directory rules with the Apply rule when device boots option unless they are required. - Concurrent device requests:
If you are experiencing problems with many concurrent device requests (delays in configuration deployment or logging on to the device), open the UMS Console and use the options under UMS Administration > Global Configuration > Device Network Settings > Device Requests (thread and queue size) to control the throughput of the device requests. Contact support for recommendations.
Limitations: UMS HA
- Device actions that are manually triggered in the UMS Console are performed by one UMS Server (the one the UMS Console is currently connected to); there is no load balancing for these actions.