Panels not loading if not visible

EDIT: It appears this feature is called Lazy Loading and there is no way to disable it. I found some similar GitHub posts about the need to make this configurable and I will jump on those.

I like to use the ‘–Dashboard–’ data source in my panels in order to reduce the number of queries against my MSSQL data source. I noticed in version 10.2.2 it seems any panel not visible will not load which breaks this functionality for me. For instance:

  • summary panel (using the ‘–dashboard–’ datasource pointing to [panel_data])
  • some other panel
  • some other panel
  • panel_data (this panel is off the screen until you scroll down due to the other panels)

I see this new function as a benefit for most users as it doesn’t load what isn’t being looked at but is a net loss for me in the long run because I can no longer reuse the data in [panel_data] meaning I will have to query my data source multiple times going forward for the same data if I want to apply different transforms.

Is there a way to force this panel off the screen to load even when not visible? Even better, can we make it load when hidden under a row (this hasn’t been possible ever to my knowledge).

I did find a work around, while not great it seems to work. Putting my master panel at the very top without a panel title and making it very small I can make it’s foot print minimal while still loading. I’d still rather have an option to force a panel to load even if not on the screen.

1 Like

Same issue reported here: Panel Datasource not accessable when using collapsed row - Grafana / Dashboards - Grafana Labs Community Forums.

That’s lazy loading and it’s a feature:

That was my assumption, however this ironically is a bigger performance hit in our case. As an example, if we have a table:

Shift, Downtime, Duration
A, Downtime 1, 20 sec
A, Downtime 2, 60 sec
A, Downtime 1, 40 sec
B, Downtime 3, 10 sec
B, Downtime 2, 30 sec

If I wanted one panel to show downtimes in Shift A and another to show downtimes in Shift B I have to perform two queries now instead of just one and using ‘dashboard panels’ to reference a single query (other scenarios are much more complex and justify this use case)

I agree Lazy loading helps with performance in many cases, what I was hoping for was an option to turn it off for certain dashboards.

Regardless, thank you for pointing me to the documentation on this feature.

So what is the root issue here you are trying to solve? Why do you want to reduce the number of queries against mssql?

We have production boards that refresh relatively frequently - every 5 to 60 seconds depending on the use case. These make queries against our SQL based historian’s and pull a lot of data, some queries are 800+ lines and take 5 to 10 seconds to load in the worst cases. You can argue that the proper solution is to fix the source data so we don’t have to do this much manipulation after the fact but that’s simply not an option for us.

Now take that query and say you want to show a stat panel, a line chart, a table, and bar chart with the same data just formatted slightly differently. I have two options:

  1. Query the data once and reference the data using dashboard panels, then use transforms to format it the way I want for each chart
  2. Query the data on each panel

In option 2, it’s the same query and hitting our data source 4 times instead of just once. Additionally we may have 30 of similar dashboards running across the plant, so now we are hitting our historians 120 times per refresh cycle instead of 30 so this issue compounds.

1 Like

Of course the proper solution is to fix the source data (indices, use of stored procedures, even maybe query against a datawarehouse/flattened data approach instead of against your OLTP database). But I see that is not an option.

grafana is a visualization tool, best effort performance improvements done in it are limited at best and probably will not scale down the road if the issue in the db is not addressed. Best to solve the issue at the root level would be my recommendation.

Thanks, that’s the plan, however we work on an enterprise level so that plant issue is also compounded by the fact we have 50+ plant’s around the world each with unique challenges making a one size fit all solution very difficult.

Thanks for the feedback, I know now at least what our limitations are with this feature.

1 Like

There is caching option, which may be useful in this case (I guess it’s available only for Grafana Enterprise):

1 Like

Lazy loading seems very useful! Does everyone just shrink the object and then stick it at the top? Anyway to get it down to 1 pixel :slight_smile:

Lazy loading seems to be a useful feature. And true, the “lazy loading” feature is not new. However, we have observed a significant change in behavior since version 10.2.

Just like cconner, we like to use the ‘-Dashboard-’ data source in our panels. We have two motivations for this: First, to reduce the number of queries, second, to reduce maintenance effort by having a smaller number of query. Sometimes there are 20 or more panels that access data via the ‘-Dashboard-’ data source.

Since the upgrade to version 10.2.x this mechanism apparently works differently. As a result, our panels only load data when we scroll to the end of the dashboard where the panel with the query is located. In all versions up to 10.1.6 this behavior was different and the panels were loaded without scrolling.

Unfortunately, we could not find any information about a change in lazy loading in the release notes and we wonder wether this behavior is still desired?

2 Likes

Same motivations here. It should be possible to disable this feature or, at least, the ‘load trigger’ should be propagated between panels until it finds the data source.

There is an open PR for this:

1 Like