The "Tuning" tab of the Manage Server window is intended for use by administrators to tune particular actions within the DataPA Enterprise web application. The options available are:

Reload dashboards open in a browser or mobile device when they are refreshed on the server

Before publishing a dashboard, you can opt for it to be refreshed automatically at set intervals by the service. If this checkbox is checked, when a dashboard is refreshed by the service any instance of that dashboard opened by a user on a mobile device or in a browser will be refreshed. If the user has made any changes to the view of the dashboard, for instance by selecting a different filter, they will be prompted for confirmation before the dashboard is refreshed as these changes will be lost.

Interval to wait between re-checking the server for dashboard requests

When a dashboard is loaded in a browser or mobile device, the server first checks to see if the dashboard will be refreshed automatically, and if it will, when the refresh is likely to finish. This time is sent to the client along with the dashboard. If the dashboard is still open in the client at this time, the client will begin polling the server to check if the dashboard has been refreshed. You can change the time interval between each request the client makes to the server using this interval. A larger time interval could mean a dashboard takes longer to be refreshed in the client, but will reduce the number of agents used and the load on the server.

Delay before a treeview node click is processed (to allow time for another node click)

Each time the user clicks on a node in a treeview to change its checked state a request is sent to the server to rebuild any object that are filtered by this treeview. To prevent multiple requests being sent to the server when a user clicks on multiple nodes in quick succession, the request is by default delayed for a short period of time, and only sent if another node is not clicked during this period.

Increasing this value will cause a longer delay between the user clicking on a node in the treeview, and the resulting filter being applied to the dashboard, but will reduce the chance of the server having to process results that will never be required.

You can prevent the delay all together by setting value to zero. However, this can result in a significant load on the server if the user clicks on multiple nodes in quick succession where the treeview is based on a large data set or has a large number of objects dependant on it.

Maximum number of dashboards with cached data

When a dashboard is loaded by the web application, the data to support that dashboard is cached by the web application. Any subsequent requests from any user that open the same dashboard will use this cached data if available. This means the process to load the dashboard will only need to load the dashboard definition, and consequently be significantly faster. To limit the amount of memory the web application uses for this cached data, this setting limits the number of dashboards for which data can be cached at any one time. If this limit is reached, and a dashboard that is not currently cached is opened, the oldest cached data is first removed to make room for the data from the new dashboard.

Period of inactivity before cached data is removed from memory

As described above, when a dashboard is loaded by the web application, the data to support that dashboard is cached by the web application. Any subsequent requests from any user that open the same dashboard will use this cached data if available. This setting determines how long the data is retained in the cache since the last time the dashboard was loaded.

Show dashboards set to refresh on open in the mobile apps

By default, any dashboard that contains one or more queries set to refresh on open will not be visible to the mobile apps. If this setting is checked, those dashboards will be visible to the mobile apps.