How many concurrent users can a VPS handle? Do the math

From users to requests

"Concurrent users" means three different things depending on who is talking:

• Registered accounts: they cost the server nothing until they log in.
• Users active at the same time: people browsing, reading, filling in a form. Each sends a request now and then, typically every 10 to 30 seconds, plus a few API calls per screen in a modern single-page app.
• Requests in flight: those the server is working on at a given instant. This is the only figure that uses CPU and memory.

You get from one to the other with Little’s law: the number of requests in flight equals the throughput, in requests per second, multiplied by the average time a request takes.

Worked example. 600 users active at once, each triggering a request every 20 seconds, make 30 requests per second. If each request takes 100 ms, the server has only 3 requests in flight on average. The real challenge lies elsewhere: in peaks and in slow requests.

What one vCPU can serve

A request holds the CPU for as long as it computes: running the code, querying the database, building the response. One vCPU therefore handles at most 1,000 ÷ t requests per second, where t is the CPU time of a request in milliseconds. Time spent waiting (on an external API, on disk) does not use the CPU, but it does tie up a worker.

With these figures, 30 API requests per second at 10 ms of CPU use 30% of a single vCPU. The same 30 requests per second on uncached WordPress pages need 3 to 9 vCPUs. A page cache exists precisely to move a page from the fourth row of this table to the second.

What memory can hold

Every request in flight is handled by a worker, and workers take memory whether they are busy or not. It is often memory, more than CPU, that caps how many requests the server handles in parallel:

• PHP-FPM: one process per request in flight, 40 to 80 MB each. pm.max_children sets the ceiling: 20 processes means 800 MB to 1.6 GB.
• Python (Gunicorn, Uvicorn): the Gunicorn docs suggest starting from (2 × number of cores) + 1 workers, at 80 to 200 MB each. An async worker keeps many requests waiting for the price of a single process.
• Node.js: one process holds thousands of waiting connections, but uses a single core; cluster mode, or PM2, runs one process per vCPU.
• The database: PostgreSQL starts one process per connection and accepts 100 by default. Beyond a few dozen active connections, a pooler such as PgBouncer beats raising max_connections.

Persistent connections (websockets, real-time notifications) count separately: they stay open, use little CPU and a few tens of kilobytes of memory each. A Node.js server holds thousands of them in a few hundred MB.

The real bottlenecks

In a real application, the server rarely saturates where you expect. The most common causes, in the order to check them:

1. A slow SQL query: a missing index turns a 2 ms query into a 2 second one that ties up a worker and a connection. pg_stat_statements on PostgreSQL, or the MySQL slow query log, points to it.
2. Cascading queries (the N+1 problem): a page that runs one query per row it displays runs hundreds of them.
3. A synchronous external call: a payment or AI API that answers in 3 seconds blocks a synchronous worker for 3 seconds.
4. Heavy work inside the request: sending email, resizing images, generating PDFs, all better moved to a job queue.
5. No caching: pages that are identical for every visitor belong in a cache, static files with the web server.

Checking it: the load test

Orders of magnitude give you a first size; a load test gives you the real one. The idea: simulate more and more users on a copy of the application, and note the point where response times break away.

wrk -t2 -c50 -d30s --latency https://staging.your-site.com/

For a full user journey (log in, browse, search), k6 describes a scenario in JavaScript and ramps the load up in stages:

import http from 'k6/http';
import { sleep } from 'k6';

export const options = {
  stages: [
    { duration: '2m', target: 100 },
    { duration: '5m', target: 100 },
    { duration: '2m', target: 300 },
    { duration: '5m', target: 300 },
    { duration: '2m', target: 0 },
  ],
  thresholds: { http_req_duration: ['p(95)<500'] },
};

export default function () {
  http.get('https://staging.your-site.com/');
  sleep(15);
}

• Test a copy, not production, and let your host know if the test targets a server they run.
• Run the test from another machine than the one under test, or the tool eats into the server’s own resources.
• Look at the 95th percentile response time, not the average: it is what your least well-served users experience.
• Watch the server during the test: htop for CPU, free -h for memory, the logs for errors.

When load grows

The order that costs least and pays back most:

1. Cache what can be cached (pages, fragments, query results) and fix slow queries.
2. Tune the number of workers to the memory and CPU available.
3. Move up to a larger size: more vCPUs and memory, with no change to the application.
4. Put the database on its own server.
5. Spread the application across several servers behind a load balancer.

The first three steps cover the vast majority of business applications, websites and APIs: several hundred users active at the same time fit on a single well-tuned server.