How to Limit Transaction Size with maxevents for Better Performance
A financial services company uses Splunk to correlate events from multiple applications. Analysts often use `transaction user_id` to group events, but they notice that this command significantly increases search time and memory usage. After investigating, they find that certain 'user_id' values are extremely frequent (e.g., service accounts) causing huge transactions with thousands of events, which exhaust search memory. The team needs to continue grouping by user_id but must avoid performance issues. They also need to preserve the ability to compute statistics like transaction duration. Which approach best addresses both concerns?
Quick Answer
The answer is to use `transaction user_id maxevents=100 maxspan=5m` because this directly addresses the performance bottleneck by capping the number of events per transaction while still allowing accurate duration calculations. The `maxevents` parameter limits transaction size, preventing the memory exhaustion caused by high-frequency user_ids like service accounts, while `maxspan` ensures transactions don’t stretch indefinitely. On the Splunk SPLK-1003 exam, this scenario tests your understanding of transaction command optimization—a common trap is thinking pre-filtering alone is sufficient, but `maxevents` is the robust fix for unpredictable data spikes. Remember, when you need to control transaction performance, think of `maxevents` as your safety valve: it stops runaway transactions without breaking correlation logic. A handy memory tip is “maxevents for memory, maxspan for time”—together they keep your searches lean and fast.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Use `transaction user_id maxspan=5m maxevents=100`
The correct approach is to use `transaction user_id maxspan=5m maxevents=100`. This limits each transaction to a maximum of 100 events within a 5-minute window, preventing huge transactions from service accounts while still allowing grouping by user_id and computation of statistics like duration. Option B directly addresses both concerns without excluding data. Pre-filtering (option C) removes data, which may lose needed events or skew results, and is less robust than bounding transaction size.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Set `maxpause=1m` to break large transactions by gaps
Why it's wrong here
If events are frequent, maxpause may still allow large transactions.
- ✓
Use `transaction user_id maxspan=5m maxevents=100`
Why this is correct
Limits both total time and event count, preventing memory overload.
- ✗
Exclude service accounts using `where user_id!="svc*"` before transaction
Why it's wrong here
Helps but does not address all large transactions; some normal users may also be large.
- ✗
Switch to `stats values(_raw) by user_id` to avoid transaction overhead
Why it's wrong here
Loses duration calculation and other transaction features.
Go deeper
Related to this question
About these practice questions
This SPLK-1002 question is part of Courseiva's 475-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
Same concept, more angles
2 more ways this is tested on SPLK-1002
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. A company uses `transaction` to group events by `order_id`. Some orders have many events (1000+). Which option should be added to prevent a single transaction from consuming too many resources?
hard- A.keepevicted=true
- B.maxspan=1h
- ✓ C.maxevents=500
- D.maxpause=5m
Why C: Maxevents=500. This option limits the number of events that can be included in a single transaction, preventing a transaction with many events (like 1000+) from consuming too many resources. Option A (keepevicted=true) retains evicted events but does not limit resource usage. Option B (maxspan=1h) limits the time span of the transaction, not the event count. Option D (maxpause=5m) limits the time between events but does not cap the total number of events.
Variation 2. Consider the following search: 'index=web | transaction sessionid maxspan=30m | where eventcount > 5 | stats avg(duration)'. An analyst notices that the search takes a long time and uses excessive memory. Which change would most likely improve performance?
hard- A.Change maxspan to 1h to allow more events.
- ✓ B.Use the stats command with values(sessionid) instead of transaction.
- C.Remove the where clause and use stats after transaction.
- D.Add a filter before transaction to reduce events.
Why B: Using the stats command with values(sessionid) replaces the resource-intensive transaction command. The transaction command buffers all events belonging to the same session within the maxspan window, consuming memory and CPU. The stats command processes events in a more efficient streaming manner, reducing resource usage. Moreover, by using stats, the search can directly aggregate events by sessionid without requiring a maxspan window or a subsequent where clause, thereby improving performance.
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This SPLK-1002 practice question is part of Courseiva's free Splunk certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SPLK-1002 exam.