Web Server Capacity Calculator

What is a web capacity calculator?

A web capacity calculator estimates the server resources needed to handle a given amount of web traffic. It helps you determine the required CPU, RAM, bandwidth, and storage for hosting a website or web application based on expected concurrent users, page size, and request rate. This prevents both over-provisioning (wasting money) and under-provisioning (poor performance).

Capacity planning involves estimating peak traffic, average response time, and resource consumption per request. A static blog needs very different resources than a dynamic web application with database queries. This tool calculates requirements for common web architectures including static sites, CMS platforms, and application servers.

How to use this tool

Enter your expected traffic (monthly visitors or concurrent users), average page size, and application type. The tool calculates recommended server specifications including CPU cores, RAM, bandwidth, and storage. It also estimates hosting costs for popular cloud providers.

Key capacity metrics

• Concurrent users — the number of users actively using your site at the same time. Typically 1-5% of daily visitors.
• Requests per second (RPS) — each page load generates multiple requests (HTML, CSS, JS, images). A page with 30 assets = 30 requests.
• Bandwidth — total data transferred. Calculated as page size * page views. A 2MB page with 100,000 monthly views = 200GB/month.
• Response time — the time to generate and deliver a response. Under 200ms is fast, under 1 second is acceptable, over 3 seconds loses visitors.

Scaling strategies

Vertical scaling means upgrading to a bigger server (more CPU, RAM). Horizontal scaling means adding more servers behind a load balancer. CDNs (Content Delivery Networks) offload static assets to edge servers worldwide, dramatically reducing origin server load. Caching (Redis, Varnish) serves repeated requests without hitting the database. For most sites under 100,000 monthly visitors, a single well-configured server with a CDN is sufficient.

Worked example

A server handles requests that each take 50 ms on average. By Little's Law, one worker completes 1 ÷ 0.05 = 20 requests per second. Eight workers give 160 requests per second at full utilisation. To stay below 70% utilisation for headroom, plan for about 112 requests per second before adding capacity.

Common mistakes

A common mistake is planning for 100% utilisation; queues grow explosively as a server nears saturation, so latency spikes long before the theoretical limit. Another is using average response time while ignoring the slow tail — a few very slow requests tie up workers and cut real throughput. Load testing with unrealistic, cache-friendly traffic also overstates capacity.

Frequently asked questions

How much RAM does a web server need?

For a static site or small CMS: 1-2 GB. For a medium WordPress/application site (under 50K monthly visitors): 2-4 GB. For high-traffic applications with databases: 8-16+ GB. The database typically consumes more RAM than the web server itself — PostgreSQL and MySQL benefit greatly from having the working dataset cached in memory.

How do I estimate peak traffic?

Peak traffic typically occurs during specific hours and can be 3-10x the average. For a business site, peak is during work hours in your target timezone. For consumer sites, evenings and weekends. Marketing campaigns, social media mentions, and news coverage can cause sudden spikes of 10-100x normal traffic. Design for 3x average as baseline, and use auto-scaling or CDN for handling unexpected spikes.

Why should I not plan for 100% server utilisation?

Queueing theory shows waiting time rises sharply as utilisation approaches 100%; at 90% a small traffic burst can cause large latency spikes. Leaving headroom — often targeting 60 to 70% — absorbs bursts, failovers, and traffic growth, keeping response times stable instead of collapsing under load.