Performance Optimization

AggreGate is a complex system and its overall performance is affected by many factors. This article provides several performance optimization hints for different components of the system.

The default AggreGate AggreGate Server distribution bundle includes an embedded database engine that may be used for test installations and production use with small number of devices. If your installation is likely to grow beyond 30-100 devices, it's recommended to use an external database server.

For very large environments with thousands of devices, the use of dedicated physical database server is highly recommended.

All data stored in AggreGate Server embedded database is loaded in memory during server startup. If your AggreGate Server consumes a lot of memory with relatively small number of devices, check size of /db subdirectory in the AggreGate Server installation directory. If it is occupies more than 100-200 megabytes, consider switching to an external database server.

The database server documentation usually has its own Performance Optimization section. Check database server administrator's manual for more information on maximizing database performance in your environment.

AggreGate Server is the central component of the system and if its performance is significantly degraded it will affect every other system component. Two key factors affecting the server performance are:

The recommended hardware parameters can be found in System Requirements section. However, some device drivers require a lot of memory and/or processing power for device communications.

Generally, AggreGate Server should be moved to a higher performance server if the long-term average CPU load exceeds 50%. Such a high load rate may cause problems or even loss of device data during peak loads.

•	If AggreGate Server response time and request processing speed decreases within a certain time after it was started

Memory concerns should be raised if AggreGate Server Memory Usage tracker reports values higher than 90%. It is important to know that AggreGate Server's Java Virtual Machine, just like any other JVM, will never use all RAM available on the machine it's running on. JVM memory use is controlled by two parameters:

If Memory Usage tracker reports a high memory usage percentage, it's necessary to increase a mamimum amount of memory (-Xmx) parameter in the AggreGate Server Launcher Properties file. Values up to the half of available physical RAM are recommended.

Setting the maximum amount of memory too high may cause AggreGate Server startup problem, as JVM needs this memory to be available in a single contiguous block (see details here). If you experience such a problem, the installation of additional physical RAM is recommended.

In very large AggreGate installations with thousands of devices, AggreGate Server is usually working under a heavy load while receiving millions of events and performing hundreds of simultaneous synchronizations. All data is stored in the database. In some cases, even a multi-processor system with more than 4 cores is not enough to perform all data processing.

For such large installations, having both AggreGate Server and database server running on the same machine may cause serious performance degradation. We recommend hosting your database server on a dedicated machine that is connected to the AggreGate Server's machine via a high-speed network interface (such as Gigabit Ethernet).

•	There are devices those event history contains more than 1 million events (and, thus, there are database tables with more than 1 million rows)

•	Amount of RAM required for good performance of your database server is more than 50% of physical RAM installed in the machine running both AggreGate Server and database server

•	The overall performance of your AggreGate installation is slow due to the high CPU load or disk paging

AggreGate Server Database configuration has two options that significantly affect system performance:

A connection pool is a cache of database connections maintained by the database so that the connections can be reused when the database receives future requests for data. Connection pools are used to enhance the performance of executing commands on a database.

•

Maximum connection pool size should be larger than the number of simultaneously connected devices with a high data transfer rate (i.e. frequent synchronizations or large number of device-generated events). For example, if you monitor 2000 devices that are polled once per hour you may leave maximum pool size as low as 200, but if you have 500 devices synchronized with the server every 5 minutes it's better to increase the maximum pool size to 500.

•	Maximum pool size must be set lower than the total number of connections allowed by the backend database to avoid database-generated errors, such as "too many connections".

•	For large installations where peak activity is significantly higher than average activity, it is recommended to increase the minimum pool size up to 20-50% of the maximum pool size.