CS5239 Chap.2 Performance Analysis Methodologies
Performance Analysis Methodologies
Why a methodology comes before any tool
Performance investigations fail most often by wandering. An engineer opens a familiar utility, notices something that looks high, tunes it, and discovers the complaint has not moved. The Week 2 lecture answers this with a single purpose for every methodology: to know where an analysis should start and how it should proceed from there.
This chapter treats the methods as a decision, not a list to memorise. Each one fits a particular kind of question, and the learning outcomes ask you to evaluate and justify that fit for a given scenario, alongside latency analysis, static tuning and bottleneck analysis. Static tuning and latency analysis appear in the same outcome statement, so expect to justify why a given scenario calls for one approach rather than another.
A good justification names the evidence the method will produce, the perspective it serves, and the next step if its first reading is inconclusive. Treat the selection itself as part of the answer, not a preamble to it.
Resource thinking against workload thinking
Every investigation takes a stance.
One stance looks outward from the hardware and asks whether processors, memory, disks, network interfaces, buses or interconnects are being asked for more than they can supply; it suits administrators and doubles as the basis of capacity planning.
The opposite stance looks inward from the application, asking what requests arrive, how long responses take and whether requests finish without error; it suits developers, and its yardsticks are throughput and latency.
Deciding which stance the complaint belongs to removes half of the menu immediately.
The checklists and what each one certifies
The USE method walks a grid of resources against three checks (utilization, saturation, errors) and certifies machine health.
The RED method walks services against request rate, errors and duration and certifies user health, which matters in microservice deployments where many small services share hosts. The tools method is the fallback when no checklist exists: enumerate the tools on hand, the metrics each reports and the interpretations each metric allows.
Workload characterization studies the input rather than the output, asking who, why, what and how the load varies.
Monitoring keeps a time series so a current reading can be judged against history, growth measured and peaks exposed.
The utilization distinction that decides many answers
Utilization can be measured as busy time divided by observation time, or as the fraction of a component's sustainable throughput in use. The two need not agree.
A device handling many tiny scattered requests can be occupied continuously while moving far less data than it could. Saturation is tied to the capacity reading: it starts when demand reaches full capacity and surplus work begins to wait in a queue.
Confusing the readings leads to the most common wrong conclusion in this topic, which is naming a busy component as the limit when a different one is actually closer to its ceiling.
How the chapter is organised
The first page builds the decision tree from perspective to method.
The second runs a full USE grid on a slow storage server, computing both utilization readings for each resource and locating the candidate limit. The third adds RED, characterization and monitoring, then closes with two practice items: one on choosing a starting method from a user complaint, one on judging saturation from raw busy time and job rates.
Work them with the page covered, then compare your reasoning line by line.
What this chapter covers
- 01
Resource analysis versus workload analysis
- 02
Choosing a methodology from the question
- 03
The USE method: utilization, saturation, errors
- 04
Time-based versus capacity-based utilization
- 05
The RED method for services
- 06
Workload characterization and monitoring
- 07
Locating a candidate bottleneck
Worked example · free
From a user complaint to a candidate bottleneck
- 2Match the complaint to a perspective and choose RED as the starting method.
- 2Compute time-based CPU utilization with U = B/T.
- 2Compute capacity-based gateway utilization and compare it with 100%.
- 2Name the candidate bottleneck and the evidence still needed for saturation.
Key terms
- USE Method
- A resource checklist that, for every CPU, memory, network interface, storage device and accelerator, checks utilization, saturation and errors to judge machine health.
- RED Method
- A service checklist that, for every service in a microservice architecture, checks request rate, errors and duration to judge user health.
- Tools Method
- A methodology that lists available performance tools, the useful metrics each provides, and the possible interpretations of each metric.
- Workload Characterization
- An analysis of the input applied to a system, covering who causes the load, why, its characteristics and how it changes over time, rather than the resulting performance.
- Saturation
- How far demand on a resource exceeds what it can process; it begins at 100% capacity-based utilization, when extra work starts to queue.
- Capacity-Based Utilization
- The proportion of a component's sustainable throughput currently in use, such as queries received per second divided by queries it can sustain per second.
Performance Analysis Methodologies FAQ
How do I decide between the USE method and the RED method?
Ask whose health is in question. USE examines each hardware resource and reports on machine health, which suits a host that is slow or overloaded. RED examines each service through request rate, errors and duration and reports on user health. In practice RED often comes first for user complaints, and USE follows on the hosts behind the slow service.
Can a disk be at 100% utilization and still not be the bottleneck?
Yes. Time-based utilization only says the disk was busy throughout the interval. If its requests are small or random it may be moving far less than its maximum throughput, so its capacity-based utilization is lower and it may not be saturated. Another resource with less headroom can be the real limit.
What does workload characterization add if the resources already look fine?
It shifts attention from performance to input. Knowing which process, user or remote address generates the load, which code path calls it, its read and write mix and variance, and whether it follows a daily pattern often explains a problem that no resource metric reveals, and it points to fixes on the demand side.
When is the tools method the right starting point?
Use it when you face an unfamiliar system without an established checklist. You list the performance tools available, record the useful metrics each reports, and note how each metric could be interpreted. It is thorough but can be slow, because it starts from whatever tools exist rather than from the question.
Why does monitoring matter for diagnosing a problem happening right now?
A single reading has no context. Monitoring keeps statistics as a time series, so the current value can be compared with the same hour last week, growth can be quantified and peaks identified. A number that looks alarming may be normal for that time of day, and only history shows it.
Assessment move
Write the selection route (question, perspective, method, candidate bottleneck, confirming metric) on one card, then for three different complaints you invent, walk the route aloud. For each resource you name, compute both U = B/T and the capacity ratio before using the word saturated.
Working through Performance Analysis Methodologies in CS5239? Sia is AskSia’s AI Computer Science tutor — ask any CS5239 Performance Analysis Methodologies question and get a clear, step-by-step explanation grounded in how CS5239 is taught and assessed. Read this chapter free, then take your hardest questions to Sia.
