Software ArchitectureAtlas

Software Architecture Atlas

Gain an overview. Understand the connections.

Quality attributeChapter I · Requirements · Building block 5 of 6

Performance

Performance describes the time behavior and capacity of a system. Significant measurements are called load, measurement point and unit.

By Michael Meierhoff · Meierhoff Systems

  1. Response timeDuration from click to confirmation.
  2. ThroughputHow much the system can do per second.
  3. Load contextEvery value needs the same load.

Context

Why this is important

A number without load, measuring point and unit cannot be checked. Percentiles show outliers that the median conceals. Shortly before saturation, the response time increases abruptly because requests wait.

Here you set and measure how quickly and to what extent the system processes requests. How the architecture achieves this is shown by the tactics below; states under load handle backpressure and timeout.

At a glance · Load, response time and throughput

Under a named load, a system shows response time and throughput; without a load figure, the two values cannot be compared.
Shop example · Playing through stages

Performance measurement with increasing load

The team measures the completion of an order with illustrative test data. The measurement includes shop processing and simulated response from the payment provider.

This is how you read the picture

  1. Response time median and 95. Increase the percentile as soon as you increase the load.
  2. Throughput The line throughput listens to 24 Orders/s to grow.
  3. Load context Each stage calls the load; only then are the four values comparable.
  • 420 msMedian response time
  • 780 msResponse time 95. Percentile
  • 20 Orders/sThroughput
  • 55 %CPU shop process

In case of: 20 Questions/requests are 95. percentile at 780 MS, just below the 800-ms threshold.

Values illustrative

Change the load and read response time, throughput, and CPU separately. Then check when it comes. 95. Percentile 800 exceeds ms. Eighths at 30 Requests to the CPU.

Tactics

This is how the architecture achieves the goal

This building block specifies and measures how fast and how much the system processes; the tactics below are own building blocks that achieve this goal.

  1. Lower load

    The shop answers frequent catalog queries from stored results instead of from the database.

  2. Load control

    Order tips are accepted and processed evenly instead of rolling over the system.

  3. Distributing resources

    Order and catalogue data are located on several units, so that reading and writing are distributed.

Benefits & limitations

Helps if:

  • An expected peak load requires proof of response time and processing capacity.
  • Response times are increasing and the cause must be narrowed down along calls and resources.

Boundaries

  • A load test measures only the tested profile: real data volumes, cold caches and network variation change the results in production. Follow up with operational SLIs.
  • More capacity can increase costs without removing the bottleneck. Find it first: measure resource use and waiting time for each dependency and track the result as an SLI.

In practice

  1. Determine the measurement point and load profile. Determine when the measurement starts and ends and what parallel use it reflects. The result makes different runs comparable.
  2. Instrument the flow and its resources. Capture the response time distribution, throughput and utilisation across the steps involved. Connect these measurements to a measurable Quality Attribute.
  3. Change one cause and measure again. Adjust the identified bottleneck and repeat the same test. An SLI can then show whether the improvement persists in production.
Read the detailed explanation

Response time is the duration of an individual request; throughput is the number of operations processed per unit of time. Resource consumption shows the capacity required to provide that performance. These values depend on the load profile, data volume and dependencies. Quality Attributes provides the overall scenario; SLIs, SLOs & Error Budgets places measurements and targets in their operational context.

Averages can hide slow cases in the tail of the distribution. Percentiles and representative load profiles show how many users experience delays. Measuring the complete flow helps distinguish the bottleneck from its symptoms. Adding capacity is effective only when it addresses the measured cause.

Little's Law connects three quantities: the average number of operations in progress equals the average throughput multiplied by the average response time. In the shop, 20 requests/s and 0.42 s give approximately 8 concurrent orders. This informs the sizing of thread pools and connections.

Check your understanding

Test yourself in three stages

  1. ReadingCheck in the picture

    At what point does the load exceed 95. Percentile 800 ms, what does the throughput do there, and what does the CPU show?

    View the solution with justification

    In case of: 30 Questions/Questions ()2.600 ms. The throughput remains at 24 Orders/s stand, the CPU is approximately 66 % And he still has air.

  2. ApplyingTransferred to a new situation

    The team wants to 30 Requests/s book twice as many CPU cores. What do you check beforehand?

    View the solution with justification

    The CPU is approximately 66 % And it's not the bottleneck. Miss first waiting times and connections to the payment provider, e.g. with the USE method (utilization, saturation, errors per resource).

  3. EvaluateWeighing an alternative

    Should the team only report the median because it is well communicated?

    View the solution with justification

    The median is simple and stable. However, it covers up the slowest responses. Together with the 95. He shows how the typical case and the slow edge differ.

Explore further

These building blocks continue the thoughts of this page.

RequirementsQuality attributesYou define measurable expectations for how well a function performs under specific conditions.Opening RequirementsAvailabilityYou determine when a function is available to users and how reliably it is provided.Opening DataCachingCaching speeds up access with stored results and governs their freshness.Opening

References

Continue on the learning path

Next in Requirements & quality: Modifiability.

6 Building blocks

Continue withModifiability