Measure first
Run a gradual load test with k6, JMeter or Locust and watch errors as well as CPU.
Server capacity & hosting calculator
How Many Users Can Your Server Handle?
Estimate concurrent users, requests per second and CPU requirements. No system-design knowledge required.
Start with one question
What do you want to find out?
Capacity visualization
What different traffic levels look like
These are load scenarios from this calculation, not benchmark data or a traffic forecast. “Overloaded” starts beyond the calculated planning capacity.
Light traffic56 RPS · 50% of capacity
Expected traffic112 RPS · 100% of capacity
Peak traffic168 RPS · 150% of capacity
Overloaded traffic128.8 RPS · 115% of capacity
Within planned limitNear limitBeyond limit
Explain the result
How was this calculated?+
CPU request capacity is CPU cores multiplied by the target CPU use, divided by CPU seconds used per request. User demand is active users multiplied by requests per minute, divided by 60.
No measured RPS was supplied, so the result uses the illustrative CPU model.
What is an active user?+
An active user is doing something now, such as opening a screen, searching or saving. Someone with the app open but idle may send no requests.
Why can 1,000 logged-in users differ from 1,000 active users?+
Logged-in users may be asleep, away or reading. Active users are sending work to the server during the same short period, so they affect capacity much more.
What happens when traffic increases?+
CPU use usually rises with request demand. Near the planned limit, queues and errors may grow. A database, network connection or external API can reach its limit before the CPU does.
How can I measure real server capacity?+
Test a safe environment with k6, JMeter or Locust. Increase traffic gradually. Watch errors, response times, CPU, memory, database load and network use. Record the highest rate that stays acceptable.
Practical next steps
Improve the evidence before you scale
Reduce processing work
Profile expensive code and move slow background jobs out of request handling.
Fix slow queries
Measure database calls, add suitable indexes and avoid repeated queries.
Add caching carefully
Cache repeated work where fresh data is not required, then measure again.
Check every bottleneck
Watch RAM, database connections, network, queues and external API limits.
Scale when evidence supports it
Add CPU cores or instances when measurements show processing capacity is the limit.
Beginner's guide
What is a Server Capacity Calculator?
A server capacity calculator turns a few workload assumptions into a planning estimate. It can estimate requests per second, simultaneously active users or CPU cores, but it cannot promise how a real application will behave.
The useful question is not simply how many people have accounts. It is how many people are active together, how often they send requests and how much processing each request needs.
How Many Users Can a Server Handle?
A server has no universal user limit. A cached website, a database-heavy web app and an AI application can use the same hardware very differently. Start with sustainable RPS, then convert that request capacity into active users using an explicit interaction rate.
If you have a measured sustainable RPS from a representative load test, use it instead of a CPU-only estimate.
How to Calculate Concurrent Users
For this calculator, "concurrent users" means people actively using the app during the same period. It does not mean every open session or logged-in account.
Expected RPS = active users x requests per active user per minute / 60
Active-user capacity = sustainable RPS x 60 / requests per active user per minute
RPS vs Concurrent Users Explained
Requests per second (RPS) measures work arriving at the server. Concurrent or active users describe people. One active person may send no request while reading, then trigger several API requests with one action.
HTTP requests in flight are different again. When latency is known, in-flight requests equal RPS multiplied by average latency in seconds; they are not a user count.
How CPU and RAM Affect App Performance
CPU cores provide processing time. The CPU model divides available core-seconds by CPU seconds used for each request and keeps the chosen utilization reserve.
RAM holds application processes, workers, runtime data and caches. User count alone cannot produce an honest RAM requirement, so memory must be measured under a realistic workload.
How to Estimate Server Requirements
Estimate active users and requests per minute first. Measure or estimate CPU time per request, choose a target CPU utilization below 100%, then round the result up to a whole CPU core.
Required CPU cores = ceiling(expected RPS x CPU seconds per request / target utilization)
Why Real Load Testing Matters
A CPU formula cannot see slow database queries, connection pools, memory pressure, network limits, queue workers or third-party APIs. A realistic load test exercises those parts together and shows where errors or unacceptable latency begin.
Test gradually in a safe environment. Use realistic user flows, watch failures as well as speed, and decide acceptable thresholds before testing.
Transparent examples
Three worked capacity examples
These figures are computed by the calculator's CPU model. They are illustrative assumptions, not measured benchmarks or hosting guarantees.
Small website
Mostly cached pages with light interaction.
- CPU
- 2 cores at 70%
- CPU time
- 8 ms/request
- Activity
- 0.5 requests/user/min
RPS = 2 x 0.7 / 0.008 = 175 RPS
Active users = 175 x 60 / 0.5 = about 21,000
Illustrative CPU estimate only. RAM, database, network and application limits are not proven.
Typical web application
Ordinary pages that read and write data.
- CPU
- 4 cores at 70%
- CPU time
- 25 ms/request
- Activity
- 2 requests/user/min
RPS = 4 x 0.7 / 0.025 = 112 RPS
Active users = 112 x 60 / 2 = about 3,360
Illustrative CPU estimate only. RAM, database, network and application limits are not proven.
API-heavy application
Frequent requests with more CPU work per request.
- CPU
- 8 cores at 70%
- CPU time
- 50 ms/request
- Activity
- 6 requests/user/min
RPS = 8 x 0.7 / 0.05 = 112 RPS
Active users = 112 x 60 / 6 = about 1,120
Illustrative CPU estimate only. RAM, database, network and application limits are not proven.
Methodology
How this estimate is built
CPU capacity
CPU-limited RPS = CPU cores x target utilization / CPU seconds per request.
Traffic demand
Expected RPS = simultaneously active users x requests per active user per minute / 60.
CPU time, not latency
CPU processing time is processor work. Latency is total elapsed response time, including waiting; latency is used only for optional in-flight requests.
Measured override
A measured sustainable RPS replaces CPU-model capacity for the active-user estimate because it can include more of the real system.
Known limits
Database work, memory, network, workers, queues, storage and external services can reduce capacity before CPU reaches its target.
Better evidence
A representative load test with explicit error and latency thresholds is more reliable than a hardware-only estimate.
Application presets are editable examples, not third-party benchmarks. Read the broader TechVodka methodology and data-source policy.
Technical references
These official documentation pages explain how established tools model users, request rates and load-test plans. They do not supply benchmark values to this calculator.
- Grafana k6: API load testing - virtual-user and request-rate workload models.
- Apache JMeter User's Manual - building and running web load-test plans.
- Locust documentation - writing user behavior and increasing request rates.
Direct answers
Server capacity calculator FAQ
How many concurrent users can my server handle?
There is no fixed number for a server size. Estimate sustainable requests per second, then multiply by 60 and divide by requests per active user per minute; a load test is needed to confirm the result.
How many users can a 4-core, 8GB server handle?
With an illustrative 25 CPU milliseconds per request, a 70% CPU target and two requests per active user per minute, the CPU model gives 112 RPS and about 3,360 active users. This is not a benchmark, and 8GB of RAM does not prove that the database, memory, network or application can sustain that traffic.
How do I calculate requests per second?
Expected RPS equals simultaneously active users multiplied by requests per active user per minute, divided by 60. For example, 1,000 active users making two requests per minute produce about 33.3 RPS.
How many CPU cores do I need for 10,000 users?
The answer depends on how often those users send requests and how much CPU each request uses. At two requests per minute, 25 CPU milliseconds per request and a 70% CPU target, 10,000 simultaneously active users create about 333.3 RPS and the CPU formula rounds up to 12 cores.
Is 1,000 concurrent users the same as 1,000 requests per second?
No. Users can pause, read or send several requests at once, so user count and request rate measure different things; 1,000 users making two requests per minute create about 33.3 RPS, not 1,000 RPS.
How much RAM does a web application need?
There is no reliable RAM requirement based only on user count. Measure the application process, worker count, cache, runtime overhead and database memory under realistic load, then keep operating headroom.
How can I test my server's actual capacity?
Use k6, JMeter or Locust in a safe test environment and increase traffic gradually. Track errors, latency percentiles, CPU, memory, database connections and network use, and define an acceptable limit before the test.
Can I estimate capacity without a load test?
Yes, a CPU model can provide an early planning estimate when its assumptions are visible. Confidence remains low until a representative load test measures the full application and its dependencies.
What is the difference between logged-in and active users?
A logged-in user may be idle and send no requests. An active user is interacting during the period being measured, so active users are more useful for estimating traffic demand.
How does a database affect server capacity?
Slow queries, locks, connection limits and storage latency can cap throughput before the application CPU is full. Include representative database work in load tests and monitor the database separately from the web server.