Can I make my dashboards load faster by scheduling the searches?

[hulahoop]

I understand summary indexing can drastically improve the load time of my dashboards. In addition, if I schedule each search in my dashboard to run on a scheduled basis, will this also improve the load performance? If so, is this because the scheduled searches will use cached assets instead of re-executing each search in the dashboard?

This would be super useful because I have a lot of summarized data and only expect this summarized data to grow.

[hulahoop · Accepted solution]

Thanks to one of our super star support engineers, the problem was discovered.

The answer to this question is YES--schedule your searches to make dashboards run faster.

The tricky thing is, if you are building dashboards with simple XML, the default is to use any cached artifacts on dashboard load. Simple XML is the XML generated by the dashboard builder in SplunkWeb. If you have not edited this XML, then you simply do not need to worry about your dashboards using the cache.

When simple XML is not expressive enough, advanced XML is required. When using advanced XML, you need to employ the useHistory parameter in the definition of the search module in order to take advantage of the cache:

<module name="HiddenSavedSearch" autoRun="True">
  <param name="useHistory">true</param>
  <param name="savedSearch">FooBar - Schedule Me</param>
  <module name="ViewRedirectorLink">
    <param name="viewTarget">flashtimeline</param>
    <param name="label">View full results</param>
  </module>
  <module name="SimpleResultsTable"></module>
</module>

[oreoshake]

I'm a big fan of summary indexing. Are you just putting the data into the index or are you running a stats command each time the search runs? (fyi, using stats on a saved search fails in 4.0.10!!! it's a bug they're working on)

For example, if your saved search was just "source=fw" and you're running stats on those results, you won't benefit from summary indexing. but "source=fw | stats count by protocol, port" you'd get what you want.

If you are doing the stats method, perhaps you should increase the span of the search and run it less frequently? This way your stats will aggregate more results, but your searches against the stats will have less data to process.

[hulahoop]

Hi Neil, that's unfortunate the stats command fails in 4.0.10. Luckily we are using '... | sistats count by foo,bar' so have not encountered this problem. Thank you for the suggestion on running the scheduled summaries less frequently. We'll keep that in mind. When using summary indexing it is necessary to balance the summary rate and the granularity. Maybe some day there will be transparent summary indexing and we don't have to make these tough decisions. 🙂

[oreoshake]

I'm curious about this too. I was under the same impression, that previous results would be loaded so long as the results are still around.

[hulahoop]

I tried this and it doesn't seem to work as expected. I have 4 searches on my dashboard, let's call them A, B, C, D. I scheduled A to run every 5 minutes. When the search kicks off, I do see the search artifacts in var/run/splunk/dispatch/scheduler_nobody_A_###_###. When I load the dashboard, I then see new search artifacts for all 4 searches listed by search ID. Each time I reload the dashboard I get 4 new search artifacts generated in var/run/splunk/dispatch. So it appears the dashboard is not using cached artifacts at all. Is this the expected behavior?