An analyst runs transaction across a week of proxy logs for every city employee to find rare destinations. Why is that an efficiency anti-pattern, and what is the better pattern?
Select an answer to reveal the explanation.
Short Explanation
transaction across a week of city proxy logs is like stacking every commuter's whole trip into RAM. If the hunt only needs grouping, stats or streamstats by user and time buckets does the job without the memory bill.
Full Explanation
Broad transaction across a week of proxy logs for every city employee is an efficiency anti-pattern because transaction holds large event sets in memory to build multi-event sessions. When the hunt only needs grouping by user and time to find rare destinations, stats or streamstats with time buckets delivers the grouping without the transaction memory bill on municipal proxy volume. Calling week-long transaction always faster than stats inverts Splunk performance guidance for this class of search. Replacing the hunt with makeresults avoids reading proxy logs entirely and cannot find rare destinations in live traffic. Adding a leading wildcard on URL makes index use worse rather than rehabilitating a heavy transaction. Exam caveat: transaction remains appropriate for true session reconstruction with tight keys and short maxspan—not as a default week-wide aggregator for rare-dest hunting. Operational check: rewrite the rare-destination hunt with stats or streamstats by user and time bucket on a constrained proxy index and window, compare memory and runtime to the week-long transaction in Job Inspector, and keep transaction only for short session stories. Document the revised SPL in the civic SOC runbook so the next on-call analyst inherits the efficient pattern rather than the anti-pattern.