How Many Concurrent Users Can Your Website Handle?
The Short Answer
It depends. A website might be able to handle anywhere from a few dozen to hundreds of thousands of concurrent users. Server specifications alone aren’t enough to narrow down that range with much precision. The same hardware or virtual machine might support 50 concurrent users for a resource-intensive application or 50,000 users for a highly optimized site.
Your application stack, database queries, caching strategy, and external dependencies often affect capacity more than the number of physical CPU cores or amount of RAM. The ranges below can give you a rough starting point, but guessing is dangerous, and the only reliable way to find your site’s capacity is to test the actual application on the infrastructure you plan to use.
If you’re not even sure how many concurrent users you need to support, start with the guide to concurrent users and how to calculate them.
In short, multiply the number of visits during your peak hour by the average session duration in hours, and then allow some headroom. A site with 5,000 visits per hour and an average 3-minute session has approximately 250 concurrent users on average during that hour, although shorter traffic spikes might be higher.
Ballpark Capacity by Hosting Setup
Treat these ranges as starting assumptions to verify with a load test, not as guaranteed limits! Two sites in the same category and even running on the same hardware can have drastically different capacity depending on how they’re built and configured.
| Setup | Rough concurrent user range | What usually breaks first |
|---|---|---|
| Static site on a CDN | Tens of thousands and up | CDN capacity or service limits |
| Cached CMS (e.g. WordPress with page caching) on decent hosting | High hundreds to a few thousand | Uncached paths: search, cart, login |
| Uncached CMS on shared hosting | A few dozen | PHP workers and the database, quickly |
| Database-backed web app on a single midsize server | Low hundreds, sometimes fewer | Database connections and slow queries |
| Autoscaled cloud application | Thousands and up | The database and other things that don’t autoscale |
There are two important patterns in this table. First, effective caching can increase capacity substantially because a cached response avoids much of the application and database work required to generate a page. Second, the capacity limit is very often caused by one specific component (the bottleneck) rather than the server as a whole. This is one reason it’s so hard to predict.
Why Server Specs Can’t Tell You Your Limit
The server process itself is often not the first bottleneck. Modern web and application servers can manage large numbers of connections, but the application and services behind them have their own limits that are usually much lower.
Common bottlenecks in web application load testing include an exhausted database connection pool, a slow query that consumes significant resources at higher concurrency, application locks that force otherwise independent work to run sequentially, worker or thread pool limits, and third-party APIs that enforce rate limits or have their own bottlenecks, among other possibilities.
These limits aren’t obvious at all from just looking at a server or VM specification, and adding CPU to the web tier won’t necessarily fix them.
How to Measure Your Real Limit With a Stress Test
You can measure your site’s actual limit by simulating realistic users, gradually ramping up the load, and observing the point where the site stops meeting your performance requirements. For this, you’ll need a load testing tool.
Build a script that follows an important user journey, for example browsing, searching, adding a product to the cart, and checking out. A load test that just hammers the homepage might miss the dynamic operations that actually limit capacity. Make sure to add realistic wait times so each bot moves through the site at approximately the pace of a real user.
Once you’ve created a script, run a stress test that ramps concurrent bots beyond your expected peak in users. For example, if you expect 250 concurrent users, you might ramp steadily to 750 or 1,000 over 30 minutes. The exact maximum depends on how much headroom you want to allow.
In Loadster, you can do this by creating a scenario with one or more bot groups that ramp gradually. You can use Protocol Bots, Browser Bots, or Playwright, depending on your application and the purpose of the test. Other tools have their own approaches but the pattern of ramping up the load is similar.
Watch the response time, error, and throughput graphs as the test progresses. For a walkthrough of the complete process, see how to load test a website.
Reading the Results: Finding the Breaking Point
There are several common signs that your system is approaching its capacity limit.
Response times might remain stable at 200 users and then start rising rapidly at 300 users. Around the same time, throughput might level off even though the bot count continues to increase. This means the system isn’t completing more work and the additional requests are piling up in queues or even in the network layer. Timeouts and connection errors might appear next, and the pages or endpoints where they occur can often help you identify the performance bottleneck.
Your application’s practical capacity is the highest level where the site still meets your standards, not the point where it becomes completely unresponsive. Let’s say your requirements are a p90 (90th percentile) response time under 2 seconds and an error rate below 1%. Your measured capacity is the highest load level where both requirements still pass.
How to Raise Your Concurrent User Capacity
Once you know your site’s current capacity and which component reaches its limit first, you can focus your effort on the tuning and optimizations that are most likely to improve it.
Caching is often a good place to start: full-page caching for anonymous traffic, object caching for expensive lookups, and a CDN for static assets. Each response served from cache reduces work on the application and database.
Database tuning might include adding an index, optimizing an expensive query, or adjusting the connection pool.
Moving slow work such as email delivery, exports, and image processing to background queues can also keep interactive requests responsive under load.
When application tuning no longer provides enough improvement, you can scale vertically with a larger server or horizontally with more servers behind a load balancer. Keep in mind that databases and other shared state typically require their own scaling strategy.
Our guides on performance tuning and capacity planning cover these subjects in more detail. Whatever you change, it’s a good idea to rerun the same test afterwards to measure the improvement and find the next bottleneck. This gives you a verified capacity number for the updated configuration.
If you’d like to measure your site’s real limit with Loadster, the free trial fuel is enough to run a few preliminary tests with no credit card required.