When you stress test an application behind Server Load Balancer (SLB) with Performance Testing Service (PTS), the SLB concurrent connection count and the PTS virtual user count typically differ. Understanding what each metric measures and why the values diverge helps you interpret monitoring data correctly.
Key concepts
SLB concurrent connections -- the total number of Transmission Control Protocol (TCP) connections on the SLB instance at a given moment, including both active and inactive connections. This count covers both PTS traffic and normal business traffic.
PTS virtual users -- the number of simulated users running your test scenario concurrently. Each virtual user executes the test script independently, similar to a "thread" in JMeter or a "user" in Locust. The concept is common in performance testing tools and is typically based on customer-side evaluation. However, it is not convenient for server-side capacity evaluation and high availability evaluation.
The difference: SLB counts raw TCP connections across all traffic sources, while PTS counts simulated users from the stress test only.
Why the numbers don't match
Three factors cause the SLB concurrent connection count to diverge from the PTS virtual user count.
Different monitoring intervals
PTS collects metrics per second. SLB collects metrics every 15 seconds or every minute. Because the two systems sample at different rates, their reported values for the same moment differ even if the underlying traffic is identical.
Production traffic on the SLB instance
An SLB instance may still have normal business traffic during stress testing. Normal user requests and other connections all contribute to the SLB concurrent connection count. As a result, the number of virtual users in PTS is basically close to or less than the number of concurrent connections of the SLB instance during a stress test.
Connection pools and Keep-Alive behavior
The interaction between Keep-Alive and think time affects the connection count:
| Condition | Effect on SLB connections |
|---|---|
| Think time shorter than Keep-Alive timeout | Connections stay open (ESTABLISHED) between requests. SLB active connection count stays close to the virtual user count. |
| Think time longer than Keep-Alive timeout | The server closes idle connections before the next request. The virtual user opens a new connection for the next request, reducing the number of active connections on SLB at any given moment -- even though the virtual user count in PTS remains unchanged. |
Active vs. inactive connections on SLB
SLB reports concurrent connections as the sum of two categories:
| Category | Definition | TCP state |
|---|---|---|
| Active connections | Connections actively transferring data. With persistent connections, a single connection can transfer multiple files at the same time. | ESTABLISHED |
| Inactive connections | Connections in all states except ESTABLISHED. | All states except ESTABLISHED |
To inspect TCP connection states on your backend server, run:
netstat -anThis command works on both Linux and Windows.
Summary
| Metric | What it measures | Sampling rate | Scope |
|---|---|---|---|
| SLB concurrent connections | Total TCP connections on the instance | Every 15 s or 1 min | All traffic (stress test + production) |
| PTS virtual users | Simulated concurrent users in the stress test | Per second | Stress test traffic only |
During a stress test, expect the PTS virtual user count to be close to or less than the SLB concurrent connection count. If the SLB count is significantly lower than expected, check whether a long think time combined with a short Keep-Alive timeout is causing connections to close between requests.