Splunk Search

Why are searches using certain fieldnames so slow?

john_byun
Path Finder

In most cases, I don't notice a huge difference when I specify a fieldname or do a free text search, but for some fields it is literally 260 times slower.

Are searches using fieldnames supposed to be slower than free text?
What is it about these particular fields that make it unbearably slow?

For instance:
index=main myusername
This search has completed and has returned 1,774 results by scanning 1,774 events in 2.65 seconds

index=main user=myusername
This search has completed and has returned 1,774 results by scanning 40,885,115 events in 689.411 seconds

Tags (4)
0 Karma

koshyk
Super Champion

Good question
In Search index=main myusername, You are searching for string of "myusername" and it is blazingly fast in Splunk.

But in search index=main user=myusername . you are searching for a key-value field. Splunk doesn't now if that's raw data, or evaluated field. So it has use the TA's , props/transforms/eventypes or enriched fields kinda.

Some good tips which I do are
=> If you are sure, that the keyword is present in raw data then do index=main myusername user=myusername
=> Use TERM if you know the key-value pair is present in the raw data
=> if its an index field, you could use double colon (::) for key-value pair

0 Karma

john_byun
Path Finder

Let me ask a slightly different question. In general, is it going to be faster using a string search compared to a field search?

0 Karma
Get Updates on the Splunk Community!

Splunk Observability Cloud | Unified Identity - Now Available for Existing Splunk ...

Raise your hand if you’ve already forgotten your username or password when logging into an account. (We can’t ...

Index This | How many sides does a circle have?

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

Registration for Splunk University is Now Open!

Are you ready for an adventure in learning?   Brace yourselves because Splunk University is back, and it's ...