Capacity or load: choose right (when sizing)

Look at this familiar image of a glass partially filled with water.

It is very easy to visualize and understand the difference between capacity and load.

• Capacity is a measure referred to the container (the glass).
• Load is a measure referred to the contents (the water).

Both quantities, capacity and load, are measured with the same unit, typically in liters (or dm3).
A benchmark is performed to measure the capacity of the glass. Capacity is the maximum load (water) the glass is able/capable to contain.
So, capacity and load have the same value when the glass is 100% filled or, to put it in other words, the capacity is equal to the load in benchmark conditions.
But, remember, capacity and load are not the same.

Let's go back to our IT world. Have a look on this second image, showing the use of a system along the time.
 

Equivalences between the glass and the machine cases should be fairly evident.

• Capacity is a measure referred to the container (the machine).
• Load is a measure referred to the contents (the workload).

And, as before, both quantities, capacity and load, are measured with the same unit: SAPS, tpm, rPerf, MHz, and so on.
A benchmark is performed to measure the capacity of the machine. Capacity is the maximum load the machine is able/capable to process (under certain conditions, of course).

The basic relationship between capacity, load and usage is:

Capacity * Usage = Load

What has it all to do with us? There are important implications and pitfalls you, a proficient sizer, must be aware of.
Let's focus in the SAPS, but also any other measurement unit could be used. When SAPS are referred to the capacity, we call them "capacity SAPS"; and when they are referred the to the load, we call them "workload SAPS".

First of all: you need to be absolutely sure on the type of SAPS you're working with.

• Benchmark: the output of a benchmark express capacity, so benchmark SAPS are capacity SAPS.
• Server rating tables: SAPS in the tables listing servers and their corresponding SAPS, are capacity SAPS.
• Live capacity analysis: when you analyze the usage of an existing system, like in the previous chart, and evaluate the peak usage, you're dealing with workload SAPS.
• Sizing tools: the output of the official SAP sizing tools (the SAP Quicksizer and SAP Sizing Guidelines) is capacity SAPS. But as they usually consider a target usage of 65%, you could easily derive the workload SAPS.
• Custom or not well documented sizing tools and procedures: they don't usually say anything about the kind of SAPS they are using, and this is incomplete, incorrect and, simply, bad.

Second: to be able to rightsize, you must use the right type of SAPS. Otherwise you're doomed to commit sizing errors:

• Undersize, with performance problems ahead.
• Oversize, with overcost problems ahead.

To illustrate this, consider the following typical scenario: customer XYZ wants to move its existing running SAP, rated 10000 SAPS, to a cloud provider offering 10000 SAPS.
As the type of SAPS is not specified, neither at the source nor at the target, we explore all possible combinations.

• Source SAPS and target SAPS are capacity SAPS: rightsized. Different containers, but with the same capacity, so the same source and target performance should be expected.
• Source SAPS and target SAPS are workload SAPS: rightsized, similar to the previuos case.
• Source SAPS express workload and target SAPS express capacity: undersizing! If you put a 10000 SAPS content in a 10000 SAPS container, the usage will be around 100%, and you know this is very dangerous, almost prohibited in sizing (OLTP).
• Source SAPS express capacity and target SAPS express workload: oversizing. The target usage will be less than the source usage, and probably you will pay for what you don't use (overcost).

Summarizing: without the right knowledge of the type of SAPS, capacity or workload, your chances are 1:2 of rightsizing, 1:4 of undersizing, and 1:4 of oversizing. Frankly speaking: inadmissible, don't you think so?