How many users can your site actually handle?
Most load tests run a fixed number of users and report a response time. User Capacity Analysis ramps load past your Performance Goals to find the exact user level where your site stops meeting its SLA. Use the defaults, or define your own thresholds.
The methodology.
Three pieces: a ramping load profile, Performance Goals you can edit, and the three capacity numbers that fall out of running the two against each other.
The ramping load profile.
Users increase in evenly-spaced steps. At each step, the test holds the user count steady for a stabilization window so response time settles before the next measurement. The default ramp uses ten steps from a small starting load to your declared maximum, and the ramp shape, step count, and step duration are all editable. The chart plots response time against concurrent users, not against clock time, so the curve shows the relationship that matters for capacity planning.
Performance Goals.
Two default thresholds, both editable: average page duration (3 seconds) and error rate (1 percent). Override the defaults with your own SLA values, set per-page goals for the transactions you care about most, or add custom goals for resources like 95th-percentile latency or specific error patterns. The capacity numbers recompute against whatever thresholds you set.
The three capacity numbers.
From the run plus the goals, three concurrent-user numbers come out:
- Minimum capacity · the highest user level at which every Performance Goal was met.
- Maximum capacity · the highest user level at which goals were satisfied within tolerance.
- Exceeded capacity · the user level at which a goal first failed.
These are the numbers a release planner needs. Not "the response time at 500 users" but "the user level at which the response time stops being acceptable."
Server monitoring on the same x-axis.
If WPLoadTester's Server Monitoring agent runs on your application hosts during the test, CPU, memory, disk, and network metrics plot against the same concurrent-user axis as response time. WPLoadTester flags any host whose resource curve correlates above 0.94 with the response-time degradation, so the saturated host and resource are visible without manual chart cross-referencing.
This is what turns "the site got slow at 2,250 users" into "the application tier hit 93 percent CPU at 2,250 users on host db-primary, and that is what dragged response time."
The question every load test ought to answer.
Web Performance shipped User Capacity Analysis in 1999 because the load testing tools available at the time answered the wrong question. "What is the response time at 500 users?" tells you nothing if your release will see 5,000. The right question is the one a release planner actually asks: at what user level does the site stop meeting its goals?
The methodology has been refined across 27 years of professional performance engagements. It is the basis for the AI Bottleneck Report in WPLoadTester 7 Cloud, which generates a written analysis of every finished test using the same framework.
Run User Capacity Analysis on your application.
User Capacity Analysis ships with every edition of WPLoadTester 7. Download the free single-machine edition to run it locally, or buy a Cloud license to run it at scale against your application.
Comparing tiers? See the Free vs Pro split.