Well, if your Splunk needs 13 seconds to scan just 14 thousand events... that looks weird. But if you have big events (like 100K-big jsons), considering your wildcard at the beginning of the search ...
See more...
Well, if your Splunk needs 13 seconds to scan just 14 thousand events... that looks weird. But if you have big events (like 100K-big jsons), considering your wildcard at the beginning of the search term, the initial search might indeed be slow. So that's the first and probably the most important optimization you can do - if you can drop the wildcard at the beginning of *1000383334*, it will save you a lot of time. Notice that Splunk had to scan over 14k events just to match two of them. That's because it can't use indexed terms, it has to scan every single raw event. Since you're extracting Odernumber (and rely on it being non-empty by including it in the BY clause for stats) using [EXT] as an anchor for your regex the [EXT] part must obviously be in your event. So if it's only in part of the events, you can use it as additional search term (square brackets are major breakers so you can just add EXT to your search terms). The inputlookup and join @ITWhisperer already covered. Dedup should _not_ be using much resources. As you can see from your job inspect table, it gets just 10 results on input and returns 2. It's not a huge amount. The main problem here is the initial search. Also if your events are big, you can drop _raw early on so you don't drag it along with you along the pipeline (you only use a few fields in your stats anyway).