How search types affect Splunk Enterprise performance

You can invoke four types of searches against data stored in a Splunk Enterprise index. Each search type impacts the indexer in a different way.

The following table summarizes the different search types. For dense and sparse searches, Splunk Enterprise measures performance based on number of matching events. With super-sparse and rare searches, performance is measured based on total indexed volume.

Search type	Description	Ref. indexer throughput	Performance impact
Dense	Returns a large percentage (10% or more) of matching results for a given set of data in a given period of time. Dense searches usually tax a server's CPU first, because of the overhead required to decompress the raw data stored in a Splunk Enterprise index. Examples of dense searches include searches that use nothing but a wildcard character, or searching any index. Examples: * index=m …| stats count by fieldA index=a sourcetype=b …| timechart count by myfield	Up to 50,000 matching events per second.	CPU-bound
Sparse	Returns a smaller amount of results for a given set of data in a given period of time (anywhere from .01 to 1%) than do dense searches.	Up to 5,000 matching events per second.	CPU-bound
Super-sparse	Returns a small number of results from each index bucket that matches the search. A super-sparse search is I/O intensive because the indexer must look through all of the buckets of an index to find the results. If you have a large amount of data stored on your indexer, there are a lot of buckets, and a super-sparse search can take a long time to finish.	Up to 2 seconds per index bucket.	I/O bound
Rare	Similar to a super-sparse search, but receives assistance from Bloom filters, which help eliminate index buckets that do not match the search request. Rare searches return results anywhere from 20 to 100 times faster than does a super-sparse search.	From 10 to 50 index buckets per second.	I/O bound