Aside from the limits for base search results, using a base search to hold large numbers will often NOT improve performance because you are taking lots of results from perhaps multiple indexers, wher...
See more...
Aside from the limits for base search results, using a base search to hold large numbers will often NOT improve performance because you are taking lots of results from perhaps multiple indexers, where you are benefiting from parallelism, and sticking them on the search head, where you only have the CPU of the single search head to then process all those results - also competing for CPU with other users of that search head. Note that the comments about doing this in the base search ...
| stats count as Total, count(eval(httpStatusCde!="200" OR statusCde!="0000")) as failures, exactperc95(respTime) as p95RespTime by _time EId followed by a post process search doing | search EId="5eb2aee9"
| stats count as Total, count(failures) as failures, first(p95RespTime) as p95RespTime by _time
... is not quite right, as you don't need another stats, because you are just getting the information calculated in the base stats, but filtering out only the EId you want. However, a point to note about stats + stats is that the second stats would not do stats COUNT, but stats sum(Total), i.e. if you wanted to get the total for EId without regard to _time, you could do something like this... | search EId="5eb2aee9"
| stats sum(Total) as Total, sum(failures) as failures, min(p95RespTime) as min_p95RespTime max(p95RespTime) as max_p95RespTime avg(p95RespTime) as avg_p95RespTime
...