Easy way to keep dashboards performant?

Hi there,

I’m still pretty new to InfluxDB (OSS), but in these few weeks I’ve been using it, I’ve accumulated already >700k entries in my “smarthome” bucket. When I set the query range to 30 days I can already clearly notice how hard my browser is working to render all that data. Having multiple queries on one dashboard makes it even more noticeable.

Now my question: What is the easy / usual way to keep the dashboards / queries performant? I would have assumed there is some kind of downsampling based on the queried range built into InfluxDB, but so far I haven’t found it. The only thing I found were instructions on manually running downsampling tasks, which feels crude. I would have to maintain different dashboards depending on whether I want to have a long-term or short-term view.

Any pointers appreciated :slight_smile:

(I’ve also talked about this in my blog post a few days ago, InfluxDB newcomer’s impressions.)

Hello @nagelp,
These resources might interest you:

Yes manually running downsampling tasks is the recommended approach generally.

In general if you can use aggregateWindow() that can help. AggregateWindow() is automatically applied to your data when you query using the Data Explorer and Query Builder for this reason.

I appreciate your blog post thank you. The complication with automatic downsampling is that there isn’t a consistent desire, approach, or requirements for downsampling data. You’ll want to set up downsampling tasks with the UI.
Here are some documentation on creating tasks with the UI:

Also described here:

Thanks, @Anaisdg . I think aggregateWindow() was the missing piece of the puzzle for me.

I’ve appended

  |> aggregateWindow(every: v.windowPeriod, fn: mean)
  |> fill(column: "_value", usePrevious: true)

to my two bigger queries, and now they load instantly no matter how large the range is. However the v.windowPeriod seems to be too large, it smoothes the data too heavily, and short peaks get lost completely. Is there a way to go shorter than v.windowPeriod but still stay dynamic?

Also, the fill() is crucial, otherwise I see heavy artefacts for shorter ranges.