The performance AQ_Statistic_Visualization container is insufficient

Problem

When using the AQ_Statistic_Process container in combination with the AQ_Statistic_Visualization container you might experience performance problems when using a large number of cases/aggregates. The performance impact depends on:

the number of cases or aggregates
the number of times the AQ_Statistic_Visualization container is displayed
the number of concurrent users
how many cases match the criteria defined in the AQ_Statistic_Process container
how many criteria are defined in the AQ_Statistic_Process container.

The more cases match and the more criteria there are, the more the performance is degraded. The expected symptoms are:

slow loading time of pages containing one or more AQ_Statistic_Process containers
overall decrease of performance
memory usage spikes on the server while rendering pages containing one or more AQ_Statistic_Process containers

The memory usage spike is per user session. If the affected pages can be viewed in multiple concurrent user sessions (i.e. not just by an "administrator" user) the memory usage increase should be multiplied by the number of concurrent user sessions rendering the affected pages.

Solution

It is recommended to avoid the following situations:

using AQ_Statistic_Process containers with very broad search criteria (which are matched by many cases)
using AQ_Statistic_Process containers on pages that are rendered very often by many concurrent user sessions (not recommended on pages accessible for end-users, landing pages, dashboards - anywhere where users will often go but without the specific intent to look at these graphs).

The performance of this container will be fixed in a next minor release.

If you encounter any problems that might be related to this issue please do not hesitate to contact Blueriq support.

Technical Details

When the search criteria of an AQ_Statistic_Process container are matched by many cases, the following actions are executed by the Runtime:

one database query is made to find the matching cases
for each batch of 1000 cases, another query is made to retrieve the attributes specified in the criteria

For example, if 100,000 cases match, then 101 database queries will be executed. The impact on performance depends on the hardware configuration, network configuration and load on the database server, and needs to be estimated on a case-by-case basis.

Since the attributes are sent over the network and temporarily stored in the Runtime memory, the memory spike depends on what kind of data is stored in the attributes and how many attributes there are. This also can only be estimated on a case-by-case basis.