CS5239 Chap.3 Capacity Planning and Service Levels
Capacity Planning and Service Levels
What capacity planning is for
Capacity planning studies how a system will behave as load grows and how it will scale. Its real deliverable is a forecast with consequences: the point in time when agreed service levels stop being met, and a cost-effective way of pushing that point further out. Three things make this difficult in practice.
Demand fluctuates from hour to hour, peaks sit well above the average, and every unit of extra capacity has to be paid for.
Outages at large online services and banks show what happens when the forecast is missing or wrong: lost revenue, regulatory penalties and reputational harm.
Capacity has more than one meaning
Nominal capacity is the throughput a system could reach under ideal workload conditions, such as the rated bandwidth of a network link.
Usable capacity is lower: it is the highest throughput at which response time still satisfies the stated limit. Knee capacity marks the load beyond which response time rises rapidly while throughput hardly improves. These three ceilings matter because operators tend to watch throughput while users experience response time, and the two pull in opposite directions as load climbs.
A plan built on nominal capacity will promise months of headroom that users never actually enjoy.
Service levels and availability
A service-level agreement records what users can expect in response time, throughput, availability and reliability. The guidance is to choose metrics users understand, to set goals that are simple to measure, and to connect IT spending to the level promised.
Availability is uptime divided by the observation period, expressed as a percentage.
Always translate it into permitted downtime: a figure that sounds high, such as ninety-nine percent, still allows several days offline per year, while the five-nines standard allows only minutes.
The modelling sequence
The process starts by inventorying the environment: client and server platforms, middleware, database systems, applications and their criticality, network layout, existing agreements and procurement rules.
A workload model then describes intensity and per-resource service demand for each request class, built from benchmarks, industry practice or direct measurement depending on what monitoring exists. Workload forecasting projects intensity forward from historical usage and business plans, with methods such as moving averages and exponential smoothing.
A performance model, usually a queueing network, predicts response time, throughput, utilisation and queue length; it is validated against measurements and recalibrated until the error falls within roughly ten to thirty percent.
A cost model separates fixed startup outlay from operating spending on hardware, software, telecommunications, electricity and support staff.
When a measured service demand comes from a test machine, scale it to production by multiplying by the ratio of the test rating to the production rating.
A faster production machine therefore shrinks the demand, which raises the ceiling.
From forecast to decision
The models meet in a cost/performance analysis that selects the cheapest configuration still inside the agreement, and the output is a configuration, investment and personnel plan. Timing is chosen through one of three provisioning strategies.
Leading adds capacity ahead of demand and suits fixed launch dates, at the risk of idle hardware. Lagging waits until limits approach and suits expensive capacity with uncertain demand, at the risk that users notice degradation first. Matching adds small increments as demand grows and suits elastic infrastructure, at the risk of falling behind a sudden burst.
Whatever the choice, the order date is the saturation date minus the provisioning delay.
What this chapter covers
- 01
Nominal, usable and knee capacity
- 02
Service-level agreements and availability
- 03
Environment, workload, performance and cost models
- 04
Workload forecasting techniques
- 05
Benchmark scaling of service demand
- 06
Lead, lag and match provisioning strategies
Worked example · free
Scaling a benchmark and dating the saturation point
- 2Scaling factor = test rating / production rating = 5.0/8.0 = 0.625; production demand = 20 x 0.625 = 12.5 ms.
- 1Nominal ceiling = 1/demand = 1/0.0125 s = 80 requests per second.
- 2Set 40 + 3t = 60 against usable capacity: t = 20/3 = 6.67 months.
- 1Order date = saturation minus delivery delay = 6.67 - 2 = 4.67 months.
Key terms
- Nominal Capacity
- The maximum throughput a system can achieve under ideal workload conditions, such as the rated bandwidth of a network link.
- Usable Capacity
- The highest throughput at which the workload still meets its specified response-time limit; the ceiling a capacity plan should use.
- Knee Capacity
- The workload level beyond which response time climbs steeply while throughput barely grows or levels off.
- Service-Level Agreement
- A stated commitment on what users can expect in response time, throughput, availability and reliability, ideally in measurable, user-facing metrics.
- Availability
- The percentage of an observation period during which the system is up, computed as total uptime divided by the period, times 100.
- Workload Forecasting
- The prediction of future workload intensity from historical usage, trends and business plans, using methods such as moving averages or exponential smoothing.
- Model Calibration
- The adjustment of a workload or performance model after comparing its outputs with measurements, repeated until the error is acceptable.
Capacity Planning and Service Levels FAQ
Why should a capacity plan use usable capacity rather than nominal capacity?
Nominal capacity is measured under ideal conditions and ignores the response-time limit users actually care about. Usable capacity is the highest throughput at which the agreed response time is still met, so it is reached earlier. Planning against the nominal figure overstates headroom and lets the service level break before any alarm is raised.
How do I turn an availability percentage into something I can judge?
Multiply the unavailable fraction by the length of the observation period. Over a 365-day year, 99 percent leaves 87.6 hours of permitted downtime, while 99.999 percent leaves about 5.3 minutes. Comparing the downtime allowance with how long a realistic outage lasts shows whether the target is meaningful.
What does benchmark scaling do to a measured service demand?
Service demand measured on a test machine is multiplied by the ratio of the test machine rating to the production machine rating. A faster production server has a higher rating, so the factor is below one and the demand falls. Lower demand per request raises the throughput ceiling before saturation.
When is a lag provisioning strategy reasonable?
Lagging suits situations where capacity is expensive and future demand is uncertain, because money is only committed once resources approach their limits. Its cost is that users experience degraded response times first. It fits poorly when the SLA carries heavy penalties or when delivery of new capacity takes months.
How accurate must a performance model be before its predictions are trusted?
The course materials treat an error of roughly 10 to 30 percent between calculated and measured response time or throughput as acceptable. If the gap is larger, the model is recalibrated, typically by revisiting service demands or workload parameters, and then compared against measurements again before it is used for prediction.
Assessment move
Take one system you know, write down its nominal and usable capacity and its SLA, then build a twelve-month forecast and solve for the saturation month and the order date. Redo the calculation with compound instead of linear growth and note how far the dates move.
Working through Capacity Planning and Service Levels in CS5239? Sia is AskSia’s AI Computer Science tutor — ask any CS5239 Capacity Planning and Service Levels question and get a clear, step-by-step explanation grounded in how CS5239 is taught and assessed. Read this chapter free, then take your hardest questions to Sia.