Background

Performance efficiency¶

Performance efficiency means giving a workload the resources its load needs, and keeping that match as the load changes. Too little and users wait; too much and resources sit idle.

What the pillar covers¶

On a traditional platform, a virtual machine is sized once, often generously, because changing it later means a change request and a maintenance window. In a cloud, size is a setting you can change. That moves the effort from guessing right the first time to measuring and adjusting over time.

Design principles¶

Principle	What it means in practice
Measure before changing	Look at what the workload actually uses before choosing a size or adding capacity
Right-size	Choose the smallest flavour that meets the load with sensible headroom
Scale out where the work can be shared	Add instances behind a load balancer for work that spreads across copies
Scale up where it can't	Move to a larger flavour for work that has to stay on one instance
Find the real bottleneck	CPU, memory, disk and network limit performance in different ways; adding the wrong one changes nothing
Review as load changes	A size that fitted last year may not fit now

Scaling out or up¶

	Scale out (more instances)	Scale up (a bigger instance)
How	Add instances behind a load balancer	Resize to a flavour with more vCPUs or RAM
Suits	Web front ends, stateless application tiers, worker pools	Single-instance databases, applications that can't run as several copies
Interruption	None for users, if the load balancer routes around new and old instances	The instance restarts during the resize
Limit	How well the application spreads across copies	The largest flavour available
Also helps	Reliability, because there is more than one instance	Nothing else directly

Scaling out suits a workload built as cattle: new instances come from the same definition as the old ones.

Measuring¶

Measure over a normal working period, and over the busiest one, before deciding.

What to look at	Windows	Linux
CPU	Task Manager or Performance Monitor, `% Processor Time`	`top` or `vmstat`
Memory	Performance Monitor, `Available MBytes` and paging	`free` and `vmstat`
Disk	Performance Monitor, disk queue length and latency	`iostat`
Network	Performance Monitor, network interface counters	`sar -n DEV` or `ip -s link`

A workload that sits near 100 percent CPU while memory is mostly free needs more vCPUs, not more RAM. One that pages to disk needs more memory. One that waits on disk needs a different storage choice, not a bigger flavour.

What it looks like on Breqwatr Cloud¶

Flavours set the size. Each flavour fixes an instance's vCPUs and RAM, and the launch form in the Breqwatr Cloud Portal (Strata) shows every flavour your project can use. Images, flavours and instances covers how they fit together.
Resize changes the flavour. An instance can be resized to a larger or smaller flavour; it restarts as part of the resize.
Load balancers spread the load. Octavia load balancers put one address in front of several instances, so capacity grows by adding instances.
BKS clusters scale by nodes. A BKS cluster can add or remove worker nodes as the workloads on it need, and can do so automatically.
Disk size is separate from flavour. The root volume's size is chosen at launch, and data volumes can be extended, so storage grows without changing the flavour.

Impact¶

Each workload runs at the size its load needs, so users get consistent response times.
Capacity follows demand instead of being bought ahead for the busiest day.
Decisions about size are based on measurements, so they can be checked and repeated.

Common anti-patterns¶

Sized once, never reviewed: a flavour chosen at launch and left unchanged as the load moves.
Bigger by default: adding vCPUs and RAM to fix a problem without finding the bottleneck first.
Scaling up what could scale out: resizing a web tier again and again when more instances behind a load balancer would carry the load without downtime.
Guessing from the dashboard once: a single look at a quiet hour rather than measurement across the busy periods.