Monitoring Splunk

How to improve switcher performance?

ehinton
Engager

Hello,

I am using a PulldownSwitcher (independent mode) with three child modules. The first child takes some time to process, as expected with a million events. Then when I use the pull-down to navigate to the second child module, the second child is visible for a moment but then it reprocesses and this takes some time. Is there any way to stop this reprocessing so that all three switcher children are loaded initially and then when I change switcher, there is no more reprocessing? Alternatively, is it possible to cache results for all the switcher modules when the view is first loaded?

Thanks

Tags (2)
0 Karma
1 Solution

sideview
SplunkTrust
SplunkTrust

Short short answer: Put a JobProgressIndicator as a sibling of the Switcher.

ie

<module name="JobProgressIndicator" />
<module name="PulldownSwitcher">
  ...

Long answer:

Although the module framework and the advanced XML take a lot of heat for being unintuitive, there are two main things that you can just learn for yourself and those two things will help it make a LOT more sense.

1) What's with the nesting, ie what's with the upstream/downstream thing?

You probably know this one already, but the answer is that if you have module A and module B, and module B is "downstream" from module A, ie it is nested, then it is potentially affected by the selected state of A, and it can leverage that selection in some way. And conversely if module B is not downstream from module A then it can not use the selected state of A in any way.

But the second issue is the more subtle one, and the one troubling you here.

2) When, where and why are searches dispatched??

Picture the data as it flows down in your view. It flows from parent modules to child modules. Let's picture the data and the various arguments flowing from one particular module in the XML, down to the N "downstream" modules that are beneath it, ie to the nested modules within it, aka the child modules. The module framework watches to see whether any of these N immediate child modules "require a search to be running". If any of them do, then the module framework temporarily reaches in, halts the data flow, marshals the search+timeRange+statusBuckets arguments it's picked up by flowing this far down, dispatches a search, and then puts various bits into the data package about the running search job. Then it steps back and lets the data flow down as before. Now however the modules at that level will all magically have a dispatched search to get data from.

So... Let's walk through the scenario with your Switcher. The data probably passes through a HiddenSearch or a SearchBar+TimeRangePicker before it gets to your PulldownSwitcher. Nobody needed the search to be running so no searches were dispatched.

Now it gets to the Switcher. The switcher doesn't need the search to be running so the undispatched arguments are now at the switcher. Moving on. The children of the switcher DO need a search to be running. This means that EVERY TIME a push is initiated from that Switcher module, the relevant search will be dispatched for the active Switcher child. Sometimes this is what you actually want -- you want the switcher changes to resubmit searches.

In your case the answer (see short answer above), is to put a JobProgressIndicator, or really any other module that "requires a search to be running" up so that it is a sibling of the Switcher module. Then when the data gets to the Switcher's layer, the search is dispatched there. Then when the Switcher pushes to its children, it's pushing a search that has already been dispatched and the framework doesn't dispatch it again.

I'm certainly not saying it's not weird!! but once you understand it your head will hurt less.

View solution in original post

sideview
SplunkTrust
SplunkTrust

Short short answer: Put a JobProgressIndicator as a sibling of the Switcher.

ie

<module name="JobProgressIndicator" />
<module name="PulldownSwitcher">
  ...

Long answer:

Although the module framework and the advanced XML take a lot of heat for being unintuitive, there are two main things that you can just learn for yourself and those two things will help it make a LOT more sense.

1) What's with the nesting, ie what's with the upstream/downstream thing?

You probably know this one already, but the answer is that if you have module A and module B, and module B is "downstream" from module A, ie it is nested, then it is potentially affected by the selected state of A, and it can leverage that selection in some way. And conversely if module B is not downstream from module A then it can not use the selected state of A in any way.

But the second issue is the more subtle one, and the one troubling you here.

2) When, where and why are searches dispatched??

Picture the data as it flows down in your view. It flows from parent modules to child modules. Let's picture the data and the various arguments flowing from one particular module in the XML, down to the N "downstream" modules that are beneath it, ie to the nested modules within it, aka the child modules. The module framework watches to see whether any of these N immediate child modules "require a search to be running". If any of them do, then the module framework temporarily reaches in, halts the data flow, marshals the search+timeRange+statusBuckets arguments it's picked up by flowing this far down, dispatches a search, and then puts various bits into the data package about the running search job. Then it steps back and lets the data flow down as before. Now however the modules at that level will all magically have a dispatched search to get data from.

So... Let's walk through the scenario with your Switcher. The data probably passes through a HiddenSearch or a SearchBar+TimeRangePicker before it gets to your PulldownSwitcher. Nobody needed the search to be running so no searches were dispatched.

Now it gets to the Switcher. The switcher doesn't need the search to be running so the undispatched arguments are now at the switcher. Moving on. The children of the switcher DO need a search to be running. This means that EVERY TIME a push is initiated from that Switcher module, the relevant search will be dispatched for the active Switcher child. Sometimes this is what you actually want -- you want the switcher changes to resubmit searches.

In your case the answer (see short answer above), is to put a JobProgressIndicator, or really any other module that "requires a search to be running" up so that it is a sibling of the Switcher module. Then when the data gets to the Switcher's layer, the search is dispatched there. Then when the Switcher pushes to its children, it's pushing a search that has already been dispatched and the framework doesn't dispatch it again.

I'm certainly not saying it's not weird!! but once you understand it your head will hurt less.

Get Updates on the Splunk Community!

Index This | I am a number, but when you add ‘G’ to me, I go away. What number am I?

March 2024 Edition Hayyy Splunk Education Enthusiasts and the Eternally Curious!  We’re back with another ...

What’s New in Splunk App for PCI Compliance 5.3.1?

The Splunk App for PCI Compliance allows customers to extend the power of their existing Splunk solution with ...

Extending Observability Content to Splunk Cloud

Register to join us !   In this Extending Observability Content to Splunk Cloud Tech Talk, you'll see how to ...