Skip to content

Optimize dashboard loading time

It's really important to optimize your dashboards loading time to improve user experience. Here are a few points to check before using a dashboard in production.

1. Avoid using hierarchical dynamic filters

In a dynamic filter, there is an option named Refresh filters on right after choice. When this option is enabled, the dashboard is usually much slower. If you don't need this feature, disable it.

The reason is that when this option is enabled, our engine will run a first query to get the entries for the first filter, and only after it has obtained these values, it will query the values for the second filter, and so on. This is required to enable that when a user selects a value, filters on the right will only show entries corresponding to the selected value.

This is very useful when filter dimensions are hierarchical (e.g. category and sub-category or country and region), but in many other cases, this is useless.

2. Avoid tabs with many widgets

When a dashboard is opened by a viewer, only the widgets of the current tab will query their data. If you have many widgets, it may take a long time.

So it is usually a better option to split your content in several tabs, each one being faster to load.

3. Check that your datasources cache is correctly configured

Serenytics provides a cache engine. When the cache is enabled on a datasource, the result of a given query on this datasource will be stored in our cache database. When this query is run again later, the query will not be sent to the datasource, our engine will only read the result in the cache. This is much faster as no computation is required and the cache database is very fast (it is based on a Redis engine).

Here is how to configure it best for your use case at hand.

Use case 1: Data updated every day

It's often the best compromise between data recency and speed of dashboard loading.

Whatever your data source, the process is the same:

  • in your data source configuration, click on "Cache data" and choose the option "until cache invalidation".
  • in the "Automation" menu, create a new task of type "Refresh dashboards cache" and schedule it every data (e.g. every day at 3 a.m.). Select the dashboard(s) whose cache must be refreshed. All caches of data sources used in the dashboards you selected will automatically be invalidated when the task runs, and the new data will be cached. When a user loads the dashboard during the day, all the data will already be in the cache. Our compute engine won't have to compute anything and the time to load the dashboard will be minimal.

Use case 2: Weekly or monthly updated data

It's the same principle as before. You just have to schedule the task every week or every month instead of every day.

Use case 3: Live dashboard

If your dashboard must have the latest data, several strategies are available in order to get the best loading performances.

If the data source is a SQL source hosted in you infrastructure, and if it's not overloaded:

In this case, it's best to use our REST API to invalidate cache from your back-end, each time you modify the data.

In every other case:

You should synchronise your data in our internal datawarehouse (and use the new Storage data sources in your dashboards). For that, you have two solutions:

  • either use a python script to synchronise the data incrementally, and schedule it for instance every 5 minutes if it's fast, otherwise every hour.
  • or push the data updates directly to our datawarehouse each time the data is modified on your side, by using ou batch API from your back-end.

Notes

  • Updating the data in Serenytics internal datawarehouse (especially via the batch method) will invalidate the data source cache automatically.
  • When you open a dashboard, you can check which queries use the cache. To do that, open the console of your browser (e.g. CMD+ALT+I on Chrome). Each data request is written in the console, with cache=disabled if the cache is not enabled on this datasource (the datasource uuid is written in the URL). It writes cache=miss if the cache is enabled but the query result was not found in cache and it writes cache=hit if the query result was found in cache.