The WPLoadTester 7 Free edition runs from a single computer, but otherwise puts no artificial cap on virtual users. That leaves an obvious question with no tidy answer: how many can your machine really simulate? It depends on your network and on the test you are running.
Ask an experienced performance engineer how many virtual users a personal computer can generate and the first thing they will do is refuse to give you a number, because the number is wrong before they finish saying it. Capacity is not a property of the machine. It is a property of the machine, the connection, and the test, multiplied together.
People reach for memory first, because memory is the thing you can read off a spec sheet. It is rarely what runs out. In a recent run on a MacBook Pro M4, WPLoadTester drove past 700 concurrent users while the generator's own processor sat at 11 percent and its memory barely moved. The machine was bored. Something else gave out first.
The order, in practice, almost always looks like this:
This is the part the spec-sheet answer misses. A virtual user is not a unit of work. It is a script, and scripts vary by orders of magnitude in what they cost to run.
Picture two of them. The first opens one page, reads it for two minutes, fills out a short form, and submits. A few small requests, long pauses, almost no data. The second clicks through an image-heavy shopping site, pulling a megabyte of pictures on every page, never pausing longer than it takes to decide what to click next. Both are "one virtual user." One of them costs a few kilobytes a minute. The other costs hundreds of times more, and will fill your connection while the first is still reading.
Four things set the cost of a virtual user:
You cannot predict load generation capacity exactly, but you can get within an order of magnitude with one line of arithmetic, because the binding constraint is usually bandwidth and bandwidth is easy to reason about:
users ≈ (usable megabits per second ÷ 8) ÷ (average page size in MB ÷ seconds per page including think time)
Take a connection with about 450 megabits per second of usable upstream, roughly 56 megabytes per second. Now run the same machine against two different tests.
Same hardware, same network, same tool. A few thousand light users, or a couple hundred heavy ones. That is the whole point: anyone who quotes you a single capacity number has not asked what your test does. (These are estimates, meant for sizing before a run, not promises.)
Here is a real run, not a hypothetical. One machine, a home connection with about 450 megabits per second of usable bandwidth, the same test case ramped from 100 to roughly 700 concurrent users. "Avg page time" is the average time to load a full page. "Throughput" is completed requests per second, the tool's measure of how much work is actually getting done.
| Users | Avg page time | Errors | Throughput |
|---|---|---|---|
| 100 | 0.23 s | 0% | 54 req/s |
| 200 | 0.30 s | 0% | 107 req/s |
| 300 | 0.53 s | 0% | 156 req/s |
| Connection saturated near here. The numbers below measure the network, not the application. | |||
| 400 | 3.34 s | 0.1% | 148 req/s |
| 500 | 6.35 s | 1.0% | 146 req/s |
| 600 | 11.45 s | 11.1% | 122 req/s |
| 700 | 20.90 s | 26.2% | 95 req/s |
Watch the throughput column, not the response times. It climbs to 156 requests per second at 300 users, and then it stops, and then it falls. That is the tell. When you add users and get less work done, the pipe is full. Response time keeps climbing only because requests are now waiting in line for bandwidth that is already spoken for.
The generator was not the problem (11 percent processor, memory flat), and the website under test was not the problem either (its processor peaked around 43 percent, plenty of headroom). Both machines had room to spare. The connection between them did not.
Look again at the 700-user row. A 21-second average page time. If you took that at face value you would file a bug against the website, schedule a war room, and start blaming the database. You would be chasing a number that has nothing to do with the application. The site did not get 90 times slower. Your connection got full. Every measurement collected after the pipe saturates is describing your own network, not the system you are trying to test, which means it is not just useless, it is actively misleading.
And the trustworthy zone ends where the throughput flattens, not where the errors start. The whole point of a load test is an accurate measurement of the system under test, and you only get that while throughput is still climbing in step with the users you add, because that is the proof your network is keeping up and the response times still belong to the website. Here that holds through 300 users, where throughput tops out at 156 requests per second. That is the maximum accurate number this machine and connection can produce for this test. Every user past it is already competing for a full pipe. Push higher for a bigger headline figure and you are not measuring harder. You are measuring nothing.
Because the real number depends on your test and your network, the only reliable way to find it is to run a small version and watch. WPLoadTester shows you everything you need while the test runs: the load generator's own processor and memory on the Engines tab, and the response-time-against-users curve that bends at the moment things go wrong. When Server Monitoring is enabled, the website's metrics plot on the same axis, so you can see at a glance whether the website ran out of room or your connection did.
Two signals tell you that you, not the website, are now the bottleneck: throughput stops rising and starts to fall, and connection-level errors (timeouts, refused connections) begin to appear. When you see those, stop adding users. You have found the edge of what this machine and connection can honestly measure.
This is a different question from how many users your site can handle, and from how many users you need to simulate to match real traffic. Both have their own tools.
How many users your site can handle · How many users you need to simulate
A home or business network was never designed to behave like thousands of web users arriving at once. It is shared, its upstream is narrow, and its routing is whatever the ISP handed you. None of that is a flaw. It is just not a measurement instrument. For building and smoke-testing your test cases, and for the low-level runs you do while developing them, generating load from the computer in front of you is exactly the right tool: free, immediate, no setup. That is most of what the Free edition is for, and it does that job well.
Accurate measurement at real scale is a different job, and it needs a different network. The cloud fixes the home network's two limits at once. Its network is engineered to carry thousands of concurrent web users, with the bandwidth and routing built for exactly that; your home connection was built to stream video to a couch. And you can launch hundreds of load generators as easily and as cheaply as one, which buys you not just raw capacity but a spread of IP addresses and geographic locations, so the traffic arrives looking like real users from real places instead of a firehose from a single home IP.
We have spent years making cloud-generated load accurate, the kind of work a home or business network was never built to support. WPLoadTester 7 Cloud distributes that load across your own AWS or Azure account, in the regions you choose. Bring Your Own Cloud means the compute runs on your bill, with no per-user markup, and the same test you built and smoke-tested locally runs in the cloud without a rewrite.
Build it locally. Measure it at scale.
The Free edition runs from the machine you already own, with no virtual-user cap and no time limit. Build your test, smoke-test it, and do your low-level runs right there, then watch where the throughput curve bends to learn your machine's honest limit. When you need an accurate measurement at real scale, the same test moves to the cloud without a rewrite.
Comparing tiers? See the Free vs Cloud split.