If you do not know how many visitors your site can serve at once, the moment you find out will probably be the worst possible one: during a campaign, a press mention, or an unexpected wave of interest.
Short answer: how is site capacity measured?
Capacity is measured not in "visitors per day" but in "requests at the same moment". Four resources decide it: processing power (CPU), memory, the concurrent process or connection limit, and the database connection limit. Whichever fills first is your capacity. The only reliable way to find it is a graduated load test that imitates real traffic; estimates and plan specifications do not reveal capacity.
The four resources that set your limit
| Resource | What happens when it fills | Early warning signal |
|---|---|---|
| Processing power (CPU) | Pages get progressively slower | Response time multiplying at peak hours |
| Memory (RAM) | Processes are killed, error pages appear | Intermittent 500 errors |
| Concurrent process limit | Requests queue, wait, then time out | "Site won't load" reports while the server looks idle |
| Database connection limit | Database errors, pages fail to open | "Too many connections" style errors |
The third row matters most. When you hit a concurrent process limit, server resources look idle — CPU at 30%, memory half free — yet the site will not load. The team checks the hardware, sees no problem, and misses that the bottleneck is a limit setting. It is the most frequently misdiagnosed capacity issue.
How to run a practical load test
- Choose a realistic scenario. Testing only the homepage misleads — it is usually cached. Test the real visitor path: home → category → product → cart.
- Increase in steps. Move through 10, 25, 50, 100 concurrent users. The aim is not to break the system but to see at which step degradation begins.
- Watch the right metric. Average response time misleads; look at the 95th percentile (the experience of your slowest 5%) and the error rate.
- Monitor the server side simultaneously. Record CPU, memory, process count and database connections during the test. Whatever fills at the breaking point is your bottleneck.
- Run it at a quiet hour, and ideally on a copy environment first. Aggressive testing on production affects real visitors.
By the end you should be able to state: "Our system responds within Y seconds up to X concurrent users; beyond X, resource Z saturates and errors rise." If you cannot form that sentence, the test is incomplete.
Early warning signals
- A growing gap between peak-hour and quiet-hour response times — resources are near their limit at peak.
- Intermittent, non-reproducible errors — usually a memory or process limit signal; "it happens sometimes" errors are not random.
- The admin panel slowing when visitor traffic rises — resources are draining from a shared pool.
- Rising database query times — data has grown while indexing stayed the same.
- The site slowing during backups or batch jobs — no headroom remains.
How much headroom should you keep?
A practical rule: normal peak-hour usage should not exceed 60–70% of total capacity. The remainder is needed for three things:
- Unexpected spikes: a campaign, a share, a seasonal effect.
- Background work: backups, reporting, bulk email.
- Degradation margin: so that one slow component does not stop everything.
If peak usage sits consistently above 85%, your system is "working" but has no margin left. That is the last point at which to wait before adding capacity — the next fluctuation will produce an outage.
Capacity planning checklist
- Do you have the last three months of resource usage graphs?
- What percentage of capacity does your peak hour consume?
- What are your concurrent process and database connection limits? (Most businesses do not know these two numbers.)
- When was the last load test?
- Is your breaking point measured, or estimated?
- Is it written down what happens if traffic doubles?
- Is monitoring configured to alert when a resource threshold is crossed?
Netişlem expert view: what gets mistaken for a capacity problem
In a considerable share of systems we are called to for capacity complaints, the problem is not insufficient resources but wasted ones.
The three cases we see most: a heavy, uncached query running on every page load; a call to an external service made on every request while the response is awaited; and bot traffic mistaken for real visitors. The third is particularly deceptive — analytics tools do not count bots, but the server still serves them. On some sites a noticeable share of server load comes from automated traffic that converts nothing.
So before recommending more capacity we always follow the same order: measure first, optimise second, scale last. Businesses that skip this order keep experiencing the same problem on a larger plan — because the waste scaled too.
Frequently asked questions
Does my daily visitor count show my capacity?
No. Ten thousand visitors spread evenly across a day is a light load; the same number compressed into an hour can strain the system. What matters is not the total but concurrency at peak.
Will a load test crash my site?
Not if it is graduated and controlled; the goal is to observe where degradation starts before reaching the breaking point. Even so, avoid aggressive testing on production, choose a quiet hour, and use a copy environment where possible.
Does caching increase capacity?
Yes, and it is often the highest-return step, because it avoids repeating the same work. But personalised content — carts, portals, member areas — cannot be cached; in such systems the gain is limited and query optimisation matters more.
Does cloud infrastructure solve capacity problems automatically?
Auto-scaling can add resources, but if the bottleneck is in the application — a single slow query, a locking table — adding resources changes nothing. Scaling works on systems written to scale.
How often should I load test?
Once a year as routine, plus before a major campaign and after any significant system change. An untested change can quietly invalidate your capacity assumptions.
Conclusion
Capacity is not the resources you own but how many concurrent users those resources actually serve. Measuring that number takes a few hours and moves your infrastructure decisions from guesswork onto data.
If you would like us to measure your system's breaking point, get in touch. You can also review our corporate hosting, VPS and CDN solutions.