Indexed real-time reads the disk instead of watching the data flow between indexing steps in memory. When a search is running though, it consumes a memory core, regardless of whether it is a real-time search or an indexed real-time search or a historical search. You can set different limits on the number of concurrent searches by type (in limits.conf) - but using indexed real-time does not inherently increase the number of possible parallel searches.
While running, an indexed real-time search performs like a historical (normal, not real-time) search at any point in time, in terms of memory use and cpu workload. The difference is that an indexed real-time search never finishes reading the data, as it is always waiting for more data to arrive on disk. However, because it uses the normal OS I/O mechanisms, an indexed realtime search can take advantage of disk caching, concurrent reads, etc., making it more efficient than a real-time search.
A real-time search monitors memory and tends to slow down the indexing of incoming data, which can lead to other problems.
However, these differences occur on the indexers - where the data is being read and indexed - and not really on the search heads (AFAIK). So you might think, "this isn't going to affect my search head at all" - but it does. All searches essentially compete for time on the indexers, so when a less efficient search runs (like any real-time search), it can affect the throughput of all searches running on the search head.
AFAIK, there are no hard numbers, as the cost/impact will depend on the workload mix (indexing vs. searching) on the indexers as well as the workload (number, size, and types of searches) running on the search head. I think the effects will be more obvious with a higher system load; for example, systems with unused cores might show little difference.
But even though there are no hard numbers, I think it means a lot when Splunk says "All real-time searches in Splunk Enterprise Security use the indexed real-time setting to improve indexing performance" in the Enterprise Security Installation and Upgrade Manual under Deployment Planning. But notice it says "indexing performance" not "search performance." I think your main performance improvement happens by not bogging down the indexers, which in turn will make the searches run faster on the search head.
Hope this helps! You might want to benchmark this a bit in your own environment.
I know this answer is not definitive and I would love to hear more from others...
... View more