Skip to content
Software Architecture Guide

Performance Efficiency

Explanation

Section titled “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

Section titled “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

Section titled “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

Section titled “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.
Section titled “Related”

Sources

Section titled “Sources”