Performance
This page outlines the performance of various stages of Atoti Limits, configurable parameters and best practices for optimal performance.
Initial load
During the Initial load we create KPIs on the connected Atoti server. Atoti Limits creates one KPI for each unique Limit Definition name property. Only one KPI can be created at a time, so the more unique Limit Names there are, the more KPIs we will have to create. We check if a KPI exists on the connected Atoti server first and only create the KPI if it does not exist.
If there are multiple limits with the same name, only one KPI is created.
Configurable properties
Alert Tasks are evaluated by executing a POST request to the /evaluate endpoint. A query is run for every Limit Definition linked to the specified KPI. If we have a KPI that is used for 100 Limit Definitions, we will run 100 queries under the hood.
alert.evaluation.parallel.tasks
This property specifies how many Alert Task queries to execute in parallel. By default, this property is set to half the number of available processors on the machine Atoti Limits is running on.
note
There is no upper limit to this value, but it should not exceed the number of processors on the machine running the connected Atoti Server instance.
| Number of Limits Evaluated | Number of Parallel Tasks | Total Time (Seconds) | Number of Processors on Atoti Server |
|---|---|---|---|
| 100 | 5 | 74 | 10 |
| 100 | 10 | 36 | 10 |
| 100 | 50 | 37 | 10 |
| 100 | 100 | 42 | 10 |
discovery-manager.polling-delay
This property specifies the frequency of updating the Remote Server Discoveries, in milliseconds. By default, it is set to 30000 milliseconds. Since Atoti Limits is connected to a remote Atoti Server instance, we need to fetch the Server, Cube, and Dimension structure from the Atoti Server instance. This process is not free and can take a few seconds. We refresh the Discoveries when we load new data, modify, or delete existing limits.
The Discoveries will only be refreshed if the Discoveries have not been refreshed for the polling-delay period, that is, current_time > last_refresh_time + polling_delay. If the last refresh time is beyond the polling delay, we will refresh the remote Atoti Server Discoveries now and update the last refresh time.
If we know an Atoti Server instance is not going to change its Cube structure frequently, we don’t need to refresh the Discoveries frequently. If we do have an Atoti Server instance that can change frequently, then setting this property to a value of -1 will cause the Discovery to always be refreshed.