# Performance Efficiency

**In short:** Performance efficiency is a workload's ability to handle rising load without hurting user experience, and to use fewer resources when demand is low. Teams should consider it from the start and verify it by measuring.

## Explanation

Performance efficiency describes how well a workload adapts to changing demand. When load rises, it scales up so users do not notice a slowdown. When demand drops, it scales down to save resources (f2).

**Capacity is one part of it.** Capacity is the degree to which the maximum limits of a product or system parameter meet requirements (f1). In plain terms: do the system's upper limits cover what the business needs?

**Start early, even without numbers.** Performance should be a core concern from the beginning, not an afterthought. This holds even when no strict targets exist yet. Teams then test and refine throughout development (f3).

**Set targets with the business.** Targets should not be purely technical. Agree with business stakeholders what user-experience effect is acceptable for the key flows (f4).

**Targets and measurements depend on each other.** You cannot measure what you have not defined, and you cannot define a target without measuring. So teams measure the workload until the group agrees on an acceptable threshold (f5).

**Keep watching in production.** Track end-to-end business transactions and technical metrics such as CPU, latency and requests per second. Use both real and synthetic transactions (f7).

Related articles: Scalability, Performance Efficiency Scenario, Performance Tactic and ISO/IEC 25010 Product Quality Model.

## Example

An online shop names "checkout" as a key flow. Together with the business, the team agrees how long a customer may wait before the delay becomes unacceptable. No measurements exist yet, so the team runs checkout under test load, records the results and adjusts the target until everyone accepts it. After launch, a synthetic purchase runs regularly. Dashboards show CPU use, latency and requests per second next to real orders.

## Trade-offs

Fine-grained performance tuning has costs in other qualities (f6). Early work should therefore look at the whole system instead of fine-tuning single components. Defining targets also takes iteration, because targets and measurements depend on each other (f5).



## Checks

- Performance targets for key flows are stated as acceptable user-experience effects and agreed with business stakeholders.
- The document says how performance is measured and how the acceptable threshold was agreed.
- Production monitoring covers business transactions and technical metrics such as CPU, latency and requests per second, with real and synthetic transactions.
- Capacity limits are stated and checked against requirements.
- Performance work is planned from the start and refined during development.

## Related

- [Scalability](https://arc.fuet.ch/concepts/quality-attributes/scalability.md)
- [Performance Efficiency Scenario](https://arc.fuet.ch/concepts/quality-attributes/performance-scenario.md)
- [Performance Tactic](https://arc.fuet.ch/concepts/tactics/performance-tactics.md)
- [ISO/IEC 25010 Product Quality Model](https://arc.fuet.ch/concepts/quality-attributes/iso-iec-25010-quality-model.md)
- [Quality Attribute](https://arc.fuet.ch/concepts/quality-attributes/quality-attribute.md)
- [Quality Attribute Trade-off](https://arc.fuet.ch/concepts/quality-attributes/architectural-trade-off-thinking.md)
- [arc42 Quality Requirements](https://arc.fuet.ch/concepts/documentation/arc42-quality-requirements.md)
- [Energy Efficiency Tactic](https://arc.fuet.ch/concepts/tactics/energy-efficiency-tactics.md)

## Sources

- [Performance Efficiency design principles - Microsoft Azure Well-Architected Framework | Microsoft Learn](https://learn.microsoft.com/en-us/azure/well-architected/performance-efficiency/principles) — learn.microsoft.com, accessed 2026-11-09
- [ISO 25010](https://iso25000.com/index.php/en/iso-25000-standards/iso-25010) — iso25000.com, accessed 2026-11-08