Reserved resources
Capacity sized by the work the application actually runs, with a measured margin and known limits.
How processing, memory and input/output are sized from the application workload without treating raw power as the answer to every problem.
Capacity planning
Three questions before adding resources
-
Load What work needs to be served?
Volume, concurrency and operation cost change demand.
-
Limit Which resource reaches its limit first?
Processing, memory and disk respond in different ways.
-
Margin How does the system behave at peak load?
Capacity without measurement may hide bottlenecks instead of solving them.
Reservation reduces unknown contention
When unrelated workloads compete for resources, an external spike can change application behavior. Reserved capacity makes that relationship more predictable and helps associate consumption with the project that produced it.
Reservation has a ceiling: the physical limit of the node. The margin is compared with observed usage and reviewed when the application changes behavior.
Each resource reveals a different kind of pressure
Processing follows computational work, memory holds temporary state and input/output reflects reads and writes. The same apparent delay may start in any one of these areas.
Consumption, queues and response time are read together. Raising one component alone usually moves the bottleneck instead of removing it.
Capacity follows demand and efficiency
Forecasts consider organic growth, campaigns, imports and product changes. Tests help relate raw resources to the amount and cost of the operations being served.
Code also changes effective capacity: a query without an index or a routine that loads everything into memory weighs more on the same machine than the difference between two server sizes.