Connection Surge
Category: Throughput · Also known as: High Number of User Connections
More sessions are connected than usual for this time of day - often an app pool leak or a retry loop opening new connections.
What this finding means
Section titled “What this finding means”The number of user connections to the instance rose well above its normal level for this time of day. This counts connections rather than active work, so it can climb steeply while the instance is doing no more real work than usual.
Why it matters
Section titled “Why it matters”Connections are a finite server resource, and unlike most pressures this one has a hard ceiling: when it is reached the instance refuses new connections and the application is down, with no gradual degradation beforehand. Because a leak climbs steadily rather than spiking, it is usually visible for hours before it becomes an outage.
How WISdom detects it
Section titled “How WISdom detects it”The User Connections performance counter is read from sys.dm_os_performance_counters, or connections are counted from sys.dm_exec_connections, each minute and compared to the four-week maximum for this minute-of-day. The rule is always evaluated and returns a value every minute.
| Collected from | Performance counter General Statistics: User Connections (sys.dm_os_performance_counters), or count of sys.dm_exec_connections. |
| Compared with | Max value for category during 15 minutes before and 15 minutes after of the same minute in the past 4 weeks |
| Related screen | Connections Details |
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 it, but the shape over the hour is what identifies the cause. A steady climb that never falls is a leak. A spike that recovers is a burst. Compare against transactions per second: connections rising while transactions stay flat means the connections are not doing anything, which is the signature of a leak.
What normally causes it
Section titled “What normally causes it”- A connection-pool leak in the application: connections opened and never disposed.
- A retry loop opening a fresh connection per attempt instead of reusing the pool.
- An application tier scaling out without a corresponding review of pool ceilings.
- Genuine growth in concurrent users.
What this finding is not
Section titled “What this finding is not”- Not a measure of load. Idle connections consume a session slot and some memory, but no CPU. High connections with low activity is a leak, not a busy server.
- Not the same as Application Overload. That finding attributes concurrent sessions to one program; this one counts connections instance-wide.
- Not fixed by raising the connection limit. That postpones the outage and makes the eventual failure larger.
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. Look for a connection-pool leak
Section titled “1. Look for a connection-pool leak”Connections climbing while the actual work stays flat is a pool that is not returning connections. Check pool size, lifetime, and disposal.
2. Attribute the new connections
Section titled “2. Attribute the new connections”Find the program and host opening them. One caller means a code change or a deployment; every caller means real growth.
3. Cap connections at the app tier
Section titled “3. Cap connections at the app tier”Bound the pool so a leak cannot exhaust the server. Containment, and it makes the next leak visible instead of fatal.