1

Hi,

We are currently running a v9 beta instance of redash, and we are trying to version control the queries and prevent the case where a logged in user or multiple users are individually refreshing the same dashboard multiple times in quick succession, as this could negatively impact our sql server instance.

For the version control aspect, I have used a gitlab repository with a gitlab-ci.yml file which uploads or updates queries to the correct datasource using the redash API, and then allows shared ownership of these queries but not alter permissions to the datasources they are in, which controls the volume of queries on Redash. I would be happy to discuss this further if anyone is interested, as this has allowed us to have version control and records of previous iterations of queries.

We think that the best approach for the dashboard refresh would be to have a “cache period” - i.e each query would return the cache result if it was under a certain age (in seconds), else it would refresh and re-execute the query to produce new results. This would limit the possibility of multiple users all pushing multiple widgets to refresh simultaneously on the same dashboard.

I wasn’t sure from looking around if this was already an existing feature, or if I would have to do something with the query results data source as a work around, if anyone could advise on the best approach to this?

Thank ya kindly.

1 Like
2

Great post.

The query results API has a max_age parameter. If a query result is available within the max_age (in seconds) you provide, the cached result is returned. Otherwise a new query execution begins.

You could modify your source code on the dashboard screen to always include the max_age parameter. At 120 this would be a two minute cache.

From these lines of code it seems that max_age is not set when you click the refresh button. So it defaults to zero and a new execution begins for all queries. You could modify the code for loadDashboard to include a max_age parameter when it calls getQueryResult.

You could enforce this on the back-end instead. Just check whether the query was executed in the last two minutes (or some configurable time) and raise an exception if it’s been too soon.

1 Like
3

Ahh, I understand, thanks a bunch @k4s1m!

I did see the max_age parameter around, but I thought it was appended to the URL of the dashboard and had some role with scheduled refreshes, rather than the refresh button itself. I would not have thought to bake it into the refresh button’s code.

I’m not sure on how specific my use case is, but do you think making that configurable on the UI on a dashboard by dashboard case would be a decent feature? In our case at least, it would give us confidence to use more intensive queries for adhoc dashboards.

Again, many thanks