Transaction Surge
Category: Throughput · Also known as: High Number of transactions/sec
The server committed far more transactions than usual this minute. Real demand, or a symptom of retries - confirm the wait signature before scaling.
What this finding means
Section titled “What this finding means”Committed transactions per second across the databases rose well above the normal rate for this time of day. This is a pure demand measure: it counts work completing, and says nothing by itself about whether the server coped with it.
Why it matters
Section titled “Why it matters”Demand surges are the finding most often misread as a capacity problem, and misreading it is expensive because the conclusion is usually to buy hardware. A surge on a healthy server is simply a busy period. A surge alongside storage or lock waits means the surge exposed an existing constraint, and the constraint is what needs fixing.
How WISdom detects it
Section titled “How WISdom detects it”The Transactions/sec performance counter is read from sys.dm_os_performance_counters each minute and compared to the four-week maximum for this minute-of-day, so a month-end peak is measured against other month-ends. This rule is always evaluated and returns a value every minute.
| Collected from | Performance counter Databases: Transactions/sec (summed across databases). |
| Compared with | Max value during 15 minutes before and 15 minutes after of the same minute in the past 4 weeks |
| Related screen | Performance Metrics |
How it is scored
Section titled “How it is scored”This rule is always evaluated, so it reports a value every minute whether or not it is elevated. It contributes an incident score of 2 when the value exceeds the four-week maximum for this minute-of-day.
How to read the numbers
Section titled “How to read the numbers”Current against History max sizes the surge. The decisive field is not on this finding at all: check the dominant wait class in Resource Bottleneck. Storage or lock class waits mean demand is not your constraint. Also compare connection count, because flat connections with rising transactions means the same callers working harder rather than a client storm.
What normally causes it
Section titled “What normally causes it”- A genuine business peak: month end, a campaign, a batch window, a release.
- A retry loop inflating the transaction count without doing more real work.
- A change in application behaviour, such as smaller transactions committing more often.
- A new caller or a scaled-out application tier.
What this finding is not
Section titled “What this finding is not”- Not a capacity signal on its own. Only treat it as capacity when the surge sustains across intervals and the waits are CPU class.
- Not a measure of user experience. Transactions per second can rise while individual response times get worse, and it can fall during the worst incidents because everything is stuck.
- Not comparable to batch requests per second. They count different things, and a divergence between the two is itself informative.
What are some possible resolutions?
Section titled “What are some possible resolutions?”The options below are ranked. Option 1 fixes the cause where it lives and costs nothing; option 3 spends money or escalates, so try it last.
1. Read the dominant wait first
Section titled “1. Read the dominant wait first”Demand is up, but demand is rarely the constraint. If the waits are storage or lock class, fix that instead and the surge stops hurting.
2. Attribute the extra work
Section titled “2. Attribute the extra work”Group by program and host. A surge from one caller is a change to investigate; a surge across every caller is genuine growth.
3. Add capacity for the workload
Section titled “3. Add capacity for the workload”Right only when the surge sustains across intervals and the waits are CPU class. Otherwise you are paying to hide a tuning problem.