Capacity Planning for a Small Web Workload

Capacity planning sounds like something reserved for teams with dashboards and headcount. For a simple web workload it is arithmetic you can do on the back of an envelope: forecast requests per second, budget memory per request, and multiply. The result is a defensible instance size and a bandwidth estimate, not a marketing guess.

Start from requests per second

Every sizing decision descends from an RPS forecast. Take your best estimate of concurrent users at peak, estimate requests per user per minute, and divide by seconds:

# 1,500 concurrent users x 2 requests per minute = 50 req/s peak
peak_rps=$(( 1500 * 2 / 60 ))
echo "peak requests/sec: $peak_rps"

If you have access logs, do the real thing: count requests in the busiest hour and divide by 3600. Never plan for the daily average; plan for the peak hour, the number you must absorb without erroring.

Budget memory per request

Measure how much resident memory one concurrent request costs in your runtime, then multiply by peak concurrency. The concurrency is not the RPS; it is how many are in-flight at once, the average latency times the arrival rate. Ten requests per second at 200 ms latency is about two in flight at any moment.

# rough in-flight = arrival rate x latency
in_flight=$(echo "50 * 0.25" | bc)   # call it 13
mem_per=64                            # MB per in-flight request
echo "budget MB: $(echo "$in_flight * $mem_per" | bc)"

Add the OS floor, a datastore cache, and a safety margin, and you have the RAM the plan must carry. If the number lands close to a plan boundary, go up one notch rather than straddle it.

CPU and bandwidth from the same peak

CPU demand comes from how many milliseconds of CPU one request burns, times the arrival rate, divided by 1000 ms per second, per core:

A request that costs 8 ms of CPU at 50 RPS wants about 0.4 cores of continuous CPU. That is well within a single core with headroom, so CPU rarely caps a lightweight web service until RPS is much higher. Bandwidth follows the payload size times RPS, and it is the number people forget until a video or image asset lands and the bill jumps.

# bandwidth: 60 KB average payload at 50 RPS
echo "KB/s: $(echo "50 * 60" | bc)"
echo "Mbit/s: $(echo "50 * 60 * 8 / 1000" | bc)"

Frame the plan around the growth rate

A capacity plan predicts a moment in time, but the plan's value is how it handles change. Work out the rate your peak RPS is growing, from the trend in your access logs, and project it forward. A service at 50 RPS today growing twenty percent a month is past 70 RPS in three months, and the instance you chose for today will not carry it. Build the projection into the resizing calendar so you act on the trend before the error rate does.

• Growing fast: size up early and keep the margin; the cost of a resize is trivial, an outage is not.
• Flat traffic: ride the smallest plan that covers your measured peak and re-check quarterly.
• Seasonal: plan for the holiday peak as the sustained state, not a special case.

Turn the numbers into a plan literally

Write the peak RPS, the in-flight count, the memory floor, and the bandwidth into a short runbook next to the deployment. When traffic is disputed, the runbook is the tie-breaker. When the box is changed, it is the audit trail. Capacity planning only pays off if the arithmetic is recorded and compared with reality after every launch, because the forecast is a starting point and the measured truth corrects it.

The plan and the re-plan

Write the numbers down, size the plan, then verify after launch. The forecast is a first draft; real traffic corrects it. Set a check one month out to compare actual peak RPS and memory against the plan, and adjust. Capacity planning is a loop, not a one-time decision.

Takeaway

Forecast the peak hour, multiply latency by arrival rate for in-flight memory, and convert request cost into cores and payload into bandwidth. Then verify against real traffic and right-size. When the forecast outgrows the box, resize on Netbay on demand from the dashboard or the API at netbayhosts.in.