On this page:

Target audience:

CAST AI Administrators

Summary: This section describes specific configuration options and best practices for one single instance of the CAST Application Analytics Dashboard when you want to upload a large number of Applications (200+).


The CAST Application Analytics Dashboard (AAD) is currently supported and tested for a use case of 200 applications maximum (see Installing and configuring the CAST Application Analytics Dashboard). For customers that have more than 200 applications to consolidate into the dashboard, this is page describes various good practices and configuration options that could help to reduce the risk of performance issues.

The main areas that can impact performance are as follows:

Deployment considerations

With regard to the deployment data sizing, please refer to Deployment - sizing to evaluate the appropriate configuration based on the number of Applications you will need to consolidated.

CAST Storage Service (CSS) installation

Install on Linux

To improve the performance of CSS, consider installing it on a Linux operating system instead of on Windows. See PostgreSQL for Linux or Docker for more information.

Isolate Measurement Service database

If the CAST Application Analytics Dashboard is going to be accessed by a high number of users, good practice is to isolate the Measurement Service database on a dedicated CAST Storage Service instance instead of installing it on the same instance used to host the Dashboard Service databases. This configuration provides improved performance with regard to the number of connections to be configured between the CAST Application Analytics Dashboard web application on Apache Tomcat and the CSS instance (see section below for more information about Tomcat configuration)

Run optimization procedures on CSS

It is good practice to run optimization procedures on the CAST Storage Service instance that is hosting your Measurement Service database on a regular basis or at least each time a Measurement Service database is deleted and restored in order to recover disk space used by deleted data. Please run the following commands:


If you are using the CAST Storage Service deployed by the CAST AIP setup, you can use the built in CSSOptimize utility to run analyze/vacuum operations against a specific database.

Tomcat configuration

Deployment on Linux

To improve performance, consider deploying Apache Tomcat on a Linux operating system instead of on Windows. Currently CAST does not provide any documentation around this, but Linux has been used successfully to host Apache Tomcat for use with the CAST Application Analytics Dashboard.

Optimize context.xml

When deploying the CAST Application Analytics Dashboard consider modifying the default configuration in the %CATALINA_HOME%\webapps\CAST-AAD\META-INF\context.xml file to manage the number of connections between the web application (CAST AAD) and the CAST Storage Service instance. Below is the default configuration provided "out-of-the-box" in the context.xml file for both Tomcat 7 and 8/8.5:

<!-- TOMCAT 7 -->
<Resource name="jdbc/domains/AAD" url="jdbc:postgresql://localhost:2280/postgres"
initConnectionSqls="SET search_path TO [Measure Schema];"
username="operator" password="CastAIP" 
auth="Container" type="javax.sql.DataSource" driverClassName="org.postgresql.Driver"
validationQuery="select 1"
initialSize="5" maxActive="20" maxIdle="10" maxWait="-1"/>

<!-- TOMCAT 8 / 8.5 -->
<Resource name="jdbc/domains/${domainName}" 
connectionInitSqls="SET search_path TO ${schema};"
username="${user}" password="${password}" 
auth="Container" type="javax.sql.DataSource" driverClassName="org.postgresql.Driver"
validationQuery="select 1" initialSize="5" maxTotal="20" maxIdle="10" maxWaitMillis="-1"/>

Please optimize the following parameters depending on the number of users and user connection profile:

Tomcat 7Tomcat 8Description



(int) The initial number of connections that are created when the pool is started. Default value is 5.

maxActivemaxTotal(int) The maximum number of active connections that can be allocated from this pool at the same time. The default value is 20.  

(int) The maximum number of connections that should be kept in the pool at all times. Default value is 10.  Idle connections are checked periodically (if enabled).



(int) The maximum number of milliseconds that the pool will wait (when there are no available connections) for a connection to be returned before throwing an exception. Default value is -1 (i.e. the pool will wait indefinitely).

The configuration of these parameters is easier to understand if you think of them as exactly corresponding to the number of cash registers you need to open to avoid having too many customers waiting in your shop to buy articles. Depending on the number of customers and period in the day, you will need to adapt the number of opened cash registers. In addition to that, these cash registers can be used for other shops in parallel. It is therefore very important to know the users' profile and when they are going to connect to your dashboard to be able to adapt these parameters:

  • Considering AAD with a lot of potential users that can connect to a unique Measurement Service database, this default configuration should be good.

Using ping to check for performance issues

If you are facing performance issues, you can run a "ping" test to check the connection between the server hosting Apache Tomcat and the server hosting CSS/Postgres. This may help you determine whether your performance issues are due to a bottleneck on your internal network. Please proceed as follows:

If the response time returned during the ping test is high, the bottleneck/issue is likely to be located on the internal network. Please contact your network administrator in this case.

Applications and Snapshots

The number of Applications consolidated into one single Measurement Service schema can impact the performance of your dashboard. CAST generally considers more than 200 Applications to be a "large" deployment where performance issues may start to appear, but this figure is not set in stone and depending on other criteria (such as the number of snapshots per Application) you may see a performance hit with a lower number of Applications (for example 20 Applications with a total of 2000 snapshots).

The number of snapshots per Application is also key as mentioned already. You may only have 20 Applications, but if the total number of snapshots in these 20 Applications is 2000 (for example) then you may see a performance hit.


The number of users that are connecting to your dashboard can impact performance:

Checking Active Directory/LDAP authentication response time

If you are using Active Directory/LDAP authentication, performance of the dashboard can be adversely affected by the response time of your Active Directory/LDAP server. To check whether this is the case, please proceed as follows:


When you are consolidating a large number of Applications, you should always actively use the data authorization feature to prevent users from viewing Applications/data they do not need to, therefore improving performance.


Homepage configuration

Each tile that is configured for display in the dashboard home page will take time to render as calculations will have to be done based on the number of applications and snapshots (e.g. to display TQI score evolution tile, the average of all snapshots to all applications must first be calculated and then the data must be displayed graphically).

Reduce the number of tiles displayed in the homepage (cmp.json)

Some tiles can be time consuming to load. Please use the following as guide to limit the number tiles in your homepage:

Provide a direct filtered URL to reduce number of Applications that load in the home page

You can provide a direct URL that points to a filter (i.e. a tag or a specific time filter). This will improve performance as not all the Applications in the portfolio need to be displayed:

To share a filtered URL simply browse to the filtered data you want to share and copy the URL from your browser's address bar, e.g.:

Performance test results

Some performance tests have been completed based on specific scenarios for the CAST Application Analytics Dashboard. These tests provide some insight into the limit of responses time depending on the number of simultaneously connected users.