(12.03-en) 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 (12.03-en) How to Configure Java Heap Size for the UMS Server and (12.03-en) 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 (12.03-en) 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.Â