Traffic curve, origin workload, and two capacity gatesLive current inputs
Computer & IT
Website Traffic Capacity Calculator
Translate monthly visits into peak-hour sessions, page requests, origin-render demand, application-worker utilization, and outbound bandwidth.
Peak visits per hour —
Concurrent sessions —
Page requests per second —
Dynamic origin requests —
Safe worker capacity —
Worker headroom —
Outbound network demand —
Network headroom —
Daily demand envelope
Daily demand envelope
Traffic curve, origin workload, and two capacity gates
The area represents page demand, the secondary line shows uncached origin work, and two gates compare worker and network utilization.
Current scenario Capacity or comparison
Result composition and constraint comparisonUpdates with every input
Planning checkpoints
Plan the traffic test and launch checkpoints
Connect the modeled peak hour to evidence from tracing, load tests, deployment behavior, and dependency limits.
Current modelLive
Review steps6
01Checkpoint
Freeze the visit and page-view definitions.
02Checkpoint
Measure a representative page and endpoint mix.
03Checkpoint
Test warm-cache and cold-cache conditions.
04Checkpoint
Run the chosen peak factor as sustained load.
05Checkpoint
Exercise deploy overlap and one-region redistribution.
06Checkpoint
Set worker, bandwidth, latency, and error alerts.
How to use the peak-hour web capacity
- Use one stable visit definition and filter monitoring, obvious bots, employee traffic, and duplicate tags. Record the data window, time zone, and exclusions.
- Seasonal services should use a comparable peak period rather than a quiet annual average.
Peak-hour web capacity fundamentals
Derive the peak multiplier
Calculate the ratio of a chosen hourly percentile to the average hour. Keep real launch and flash-crowd behavior that the service is expected to survive.
Model regional peaks and failure redistribution; global totals can hide one saturated region.
Calculation method
Convert audience volume into a peak critical-hour resource budget
The model converts audience demand into a peak-hour arrival rate, active sessions, page transactions, dynamic origin work, and transferred bytes. Worker and network budgets are evaluated separately because either can become the limiting gate.
Detailed calculation process and general formulas
V_avg,h = V_month / 720V_peak,h = V_avg,h x kConcurrent = V_peak,h x d / 60R_page = V_peak,h x p / 3600R_origin = R_page x (1 - c)R_worker = W x u x 1000 / tB_need = R_page x q x 8 / 1000U_worker = R_origin / R_workerU_network = B_need / B Every formula above uses the current calculator's own quantities. The live worked example later on this page substitutes the entered values and reconciles the result.
Reading the analysis
Measure dynamic work
An analytics page view may map to several API calls or no origin render at all. Use request traces and a weighted page mix when templates have different cost.
Measure active worker occupation under realistic database and dependency load rather than browser-perceived latency.
Improving the plan
Treat caching by layer
CDN edge, reverse proxy, application-object, and database cache hits are different measurements. This page uses the share that avoids dynamic origin rendering.
Test cold starts, invalidation, deploys, and stampede protection because a monthly cache average may collapse during the planned peak.
Decision scale
Validate with load tests
- Reproduce the entered page mix and arrival pattern.
- Test sustained load, a burst, cold cache, and deploy overlap.
- Measure correctness, latency percentiles, queue depth, cache behavior, and dependency throttling.
- Reconcile observed origin requests and bytes with this model.
More marginMore resilience to variation Less marginMore sensitive to assumptions
The live result above supplies the current decision point.
Scenario comparison
Peak-factor sensitivity
This comparison holds the other current inputs constant so the selected policy or demand assumption remains the variable under review.
| Peak multiplier | Visits/hour | Concurrent sessions | Page requests/s | Origin requests/s | Bandwidth | Binding gate |
|---|
Worked example
Your complete peak-hour web capacity calculation, step by step
This example follows the values currently entered above and updates whenever an input changes.
Scope and limitations
Model limitations
This steady-state screen excludes bots, TLS and connection overhead, database contention, autoscaling lag, long-lived connections, uploads, video streaming, third-party assets, and strict queueing-latency guarantees.
Key terminology
Peak-hour web capacity glossary
- V_month
- monthly visits; measured in visits/month.
- k
- peak-hour multiplier; measured in ratio.
- d
- average session duration; measured in minutes.
- p
- pages per visit; measured in pages/visit.
- c
- origin-avoidance cache hit; measured in decimal.
- W
- application workers; measured in workers.
- t
- active render time; measured in ms/request.
- q
- transferred page size; measured in KB/page.
- B
- safe outbound bandwidth; measured in Mbps.
Important note
This result is a first-order capacity budget, not a latency guarantee. Validate the modeled request mix, cache behavior, downstream limits, and scaling delay with representative load tests.
Frequently asked questions
Why is concurrency different from requests per second?
Concurrency counts active sessions over time; request rate counts page transactions arriving each second.
Does cache hit rate reduce bandwidth?
Not necessarily. An edge-cached response still travels to the user even though it avoids origin rendering.
What peak factor should I use?
Use an hourly percentile tied to the service objective, then model named campaigns and regional failures separately.
Does autoscaling remove the need for headroom?
No. Detection, provisioning, initialization, health checks, and cache warming take time.
Is worker fit a latency guarantee?
No. Validate latency and downstream constraints with representative load testing.