CS5239 Performance Analysis of Computer Systems
The Complete Study & Assessment Guide · Sem 1 AY26/27CS5239 Overview
- National University of Singapore
- Semester 1, AY2026/27
- Postgraduate
- 4 units
- Continuous assessment only
What the course is about
CS5239 introduces analytical and measurement techniques for understanding and improving the performance of computer systems.
- Two open-book tests carry half Test 1 at 20% and Test 2 at 30% are individual, in person and open book; the other 50% is team work.
- The project is the largest component The team project is worth 35% and is due in reading week, after the presentation in week 13.
- Pick the model from the data given Measured counts and busy times call for operational laws; stated rates with Poisson arrivals call for a Markovian queue.
- Throughput is capped by one device The largest service demand sets the throughput ceiling, so only improving that device raises it.
How CS5239 is assessed
| Component | Weight | Format |
|---|---|---|
| Test 1 | 20% | Individual. Held on the Tuesday of week 6, in person, pen and paper, open book. |
| Paper review | 10% | Team. Due on the Tuesday of week 10. |
| Test 2 | 30% | Individual. Held on the Tuesday of week 12, in person, pen and paper, open book. |
| Presentation of the project or paper | 5% | Team. Presented on the Tuesday of week 13. |
| Project | 35% | Team. Due on the Tuesday of reading week. |
The five published weights total 100%, all continuous assessment; in reading week the schedule lists only the project deadline. The assessment page states weights, weeks and whether each component is individual or team work; it states no hurdle or minimum-mark condition, so none is claimed here in either direction. Detailed requirements for the paper review, presentation and project are released on Canvas.
Current CS5239 dates
| Date | Item | Control |
|---|---|---|
| 11 August 2026 | First lecture | The welcome page names Tuesday 11 August as the first lecture; tests and deadlines fall on Tuesdays of the weeks listed in the assessment table. |
Dates are as published in the course materials published for this offering. Confirm exact deadlines and submission settings in the live LMS.
What CS5239 covers
Nine chapters follow the analytic lectures in order, from the vocabulary of performance and the choice of method, through capacity planning and probability, to queueing models, operational laws and the bounds that locate a bottleneck.
Performance Metrics and Terminology
Latency, response time, throughput, utilisation, saturation and the bottleneck, used to match a metric to a decisionWhy the vocabulary comes first
Every later tool in the course, from queueing models to the USE method and bottleneck analysis, assumes you can name what a number measures before you reason about it.
- Choosing a metric by the decision it informs
- Response time as wait plus service plus transfer
- Narrow and broad meanings of latency
- Throughput, IOPS and workload
- Time-based against capacity-based utilisation
- Saturation, queueing and the bottleneck
Performance Analysis Methodologies
Choosing a method from the question asked, the USE method and workload characterisationWhy 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.
- Resource analysis versus workload analysis
- Choosing a methodology from the question
- The USE method: utilization, saturation, errors
- Time-based versus capacity-based utilization
- The RED method for services
- Workload characterization and monitoring
Capacity Planning and Service Levels
Service levels, demand forecasts, the point where capacity runs out, and the cost of each configurationWhat capacity planning is for
Capacity planning studies how a system will behave as load grows and how it will scale.
- Nominal, usable and knee capacity
- Service-level agreements and availability
- Environment, workload, performance and cost models
- Workload forecasting techniques
- Benchmark scaling of service demand
- Lead, lag and match provisioning strategies
Probability Distributions for Workload Models
Random variables, mean and variance, Poisson arrivals, exponential inter-arrival times and the memoryless propertyWhy a performance course needs probability
How fast a computer system responds depends on what is asked of it, and what is asked of it is rarely fixed.
- Random variables as numeric outcomes of uncertain experiments
- Probability mass, density and cumulative distribution functions
- Expectation, variance and standard deviation
- Location, scale and shape parameters across six distribution families
- Poisson arrivals and exponential inter-arrival times
- Memoryless property, splitting and pooling of Poisson streams
Queueing Systems, Kendall Notation and Little's Law
Components of a queue, open and closed networks, Kendall notation, the stability condition and Little's lawWhy a model before a measurement
Performance questions usually arrive before the hardware does. Will the response time hold if demand doubles?
- Analytic models: workload and system inputs, performance predictions
- Stochastic, Markov and Poisson processes
- Components of a single service centre
- Open versus closed queueing networks: interactive and batch
- Kendall notation A/S/m/K/N/SD and its defaults
- Rules for all queues and the stability condition
Birth-Death Processes and the M/M/1 Queue
State-transition diagrams, balance equations and the single-server utilisation, queue length and response timeWhat this chapter sets out to do
Earlier chapters described a queue in words and in Kendall notation. This one makes a queue computable.
- Markov chains and the memoryless property
- Poisson counts versus exponential times
- Birth-death state-transition diagrams
- Balance equations and the product formula
- M/M/1 state probabilities and stability
- Utilisation, mean jobs and mean response time
Multi-Server Queues and Queueing Networks
M/M/m and M/M/m/K queues, blocking, product-form networks and a reliability modelWhy one server is no longer enough
The single-server queue gives clean closed forms, but real systems rarely look like one counter.
- M/M/m birth-death rates and traffic intensity
- Probability of queueing and M/M/m delay metrics
- One shared queue versus separate queues versus one fast server
- M/M/m/K blocking, effective arrival rate and loss rate
- Product-form solutions and open Jackson networks
- Data-centre reliability with MTTF, MTTR and repair staff
Operational Laws
Utilisation, forced flow, service demand, Little's law and the general and interactive response time lawsWhy measured means are enough
Earlier queueing models start from an assumed arrival process and an assumed service distribution, then derive averages. Operational analysis reverses that order.
- Operational quantities from arrivals, busy time and completions
- Visit ratios and service demand per job
- Utilization law and the bottleneck device
- Forced flow law linking device and system throughput
- Little's law at a device and for the whole system
- General and interactive response time laws
Performance Bounds and Bottleneck Analysis
Asymptotic and balanced system bounds, the knee, bottleneck identification and modification analysisWhy bounds come before models
Solving a queueing network exactly needs assumptions and arithmetic; bounding one needs only a handful of measured numbers.
- Optimistic throughput ceiling 1/Dmax
- Response-time floors D and NDmax minus Z
- Pessimistic bounds N/(ND+Z) and ND
- Knee population N* = (D+Z)/Dmax
- Primary and secondary bottlenecks
- Modification analysis of upgrade options
The course description places analytical modelling first: operational analysis and stochastic queueing network models give a framework for reasoning about bottlenecks, throughput limits and end-to-end latency.
It then moves into practical measurement through monitoring, instrumentation, profiling, workload characterisation and benchmarking, using observability tools to collect data, interpret metrics, test hypotheses and diagnose problems across hardware and software layers.
How the teaching sequence builds
The tentative schedule opens with course administration and an introduction, then methodologies and capacity planning in week 2 alongside lecture notes reviewing probability and statistics.
Week 3 introduces queueing theory, week 4 covers Markovian queueing models and week 5 operational analysis. After background in operating systems in week 6, the second half turns to observability tools, resource analysis, monitoring and visualisation, performance analysis on GPGPU, and applications, benchmarking and case studies.
This guide works through the analytic lectures in detail, because they supply the reasoning the measurement half applies.
What students are expected to be able to do
The learning outcomes ask you to explain key metrics such as latency, utilisation and saturation; to analyse performance with measurement and analytical models and draw evidence-based conclusions; to model performance with queueing theory and operational analysis; to justify the choice among methodologies such as the USE method, workload characterisation, latency analysis, static tuning and bottleneck analysis; and to optimise a system by finding its bottleneck and designing an improvement.
How it is assessed
The whole grade is continuous assessment.
Two individual tests, held in person with pen and paper and open book, carry 20% and 30%. Three team components carry the rest: a paper review at 10%, a presentation of the project or paper at 5%, and a project at 35% due in reading week.
In reading week the schedule lists only the project deadline.
Preparing for the prerequisites
The syllabus lists prerequisites in programming, operating systems and probability or statistics for undergraduates taking the course.
That mix shows up immediately: queueing models assume comfort with exponential and Poisson distributions, and the measurement lectures assume familiarity with operating-system resources. If either feels rusty, the probability chapter here is the place to start.
Worked example · free
Response time of a single-server queue from rates
- 2Check stability and compute utilisation as the arrival rate divided by the service rate: 18 / 24 = 0.75.
- 2Apply the M/M/1 mean response time, one over the difference of the rates: 1 / (24 - 18) = 1/6 s, about 167 ms.
- 2Use Little's law, arrival rate times response time: 18 x 1/6 = 3 requests in the system on average.
Key terms
- Response Time
- The total time for an operation to complete, including time spent waiting, time spent being served and time to transfer the result.
- Throughput
- The rate at which work is completed, such as requests or transactions finished per second.
- Utilisation
- The fraction of an observation interval during which a resource is busy serving requests.
- Saturation
- The backlog of requests waiting at a resource because it cannot serve them all at once.
- Bottleneck
- The resource whose limit constrains the performance of the whole system, identified in closed analysis by the largest service demand.
- Kendall Notation
- A compact code such as M/M/1 describing a queue by its arrival process, service distribution and number of servers, with optional capacity terms.
- Little's Law
- The relation that the mean number in a system equals throughput multiplied by mean time in the system, valid in steady state.
- Service Demand
- The total service time a single job needs at one device across all its visits, equal to visits multiplied by time per visit.
- Capacity Planning
- The process of forecasting when demand will exceed what a configuration can serve at the required service level, and choosing a cost-effective change.
CS5239 FAQ
How is the course graded across the semester?
The grade is entirely continuous assessment across five components: Test 1 at 20%, a team paper review at 10%, Test 2 at 30%, a team presentation at 5% and a team project at 35%. Reading week carries only one deadline on the schedule, the project, so the last stretch of the semester is team work rather than individual revision.
What format do the two tests take?
Both tests are individual and held in person with pen and paper, and both are open book. Test 1 is on the Tuesday of week 6 and Test 2 on the Tuesday of week 12. Open book shifts the challenge from remembering formulas to choosing the right model quickly and applying it without unit slips.
When should operational laws be used instead of a queueing model?
Operational laws relate quantities measured over a finite interval, such as completions, busy time and visit counts, and they need no assumption about distributions. A Markovian queueing model is the right tool when a problem states arrival and service rates and assumes Poisson arrivals with exponential service times.
How do you find the bottleneck in a closed system?
Compute each device's service demand as visits multiplied by service time per visit, and pick the largest. That device caps throughput at one over its demand regardless of how many users join, so improving any other device leaves the ceiling unchanged.
Why does response time grow so sharply as utilisation approaches one?
In a single-server Markovian queue the mean response time is one over the gap between service and arrival rates. As that gap shrinks the time grows without bound, so a server at 90% utilisation responds ten times more slowly than an idle one, not just slightly more slowly.
What does capacity planning try to answer?
It asks when forecast demand will push a system past its required service level and which configuration change restores that level most cost-effectively. The lecture frames it around service levels, workload forecasts, models and cost rather than raw hardware counts.
Questions students ask in each CS5239 chapter
- Is latency the same thing as response time?
- Sometimes. In its strict meaning latency is only the time an operation spends waiting before service starts, while response time adds the service itself and the transfer of the result. Some tools and contexts use latency for the whole operation, so always check which sense a reported figure uses before comparing it with another. Chapter 01 · Performance Metrics and Terminology
- 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. Chapter 02 · Performance Analysis Methodologies
- Why should a capacity plan use usable capacity rather than nominal capacity?
- Nominal capacity is measured under ideal conditions and ignores the response-time limit users actually care about. Usable capacity is the highest throughput at which the agreed response time is still met, so it is reached earlier. Planning against the nominal figure overstates headroom and lets the service level break before any alarm is raised. Chapter 03 · Capacity Planning and Service Levels
- How do Poisson arrivals relate to exponential inter-arrival times?
- They are two views of the same process. If arrivals in a window of length t are Poisson with mean lambda t, the first arrival comes after t only when that window holds zero arrivals, which has probability e^-lambda t. That is the exponential tail, so gaps are exponential with mean 1/lambda, and the reverse implication also holds. Chapter 04 · Probability Distributions for Workload Models
- Does Little's law require exponential arrivals or FCFS service?
- No. The law holds whatever the queueing order, the shape of the arrival gaps or service times, and however many queues there are. What it does need is a well-defined boundary, long-run balance between jobs entering and jobs completing, and finite averages, which in practice means a stable system observed in steady state. Chapter 05 · Queueing Systems, Kendall Notation and Little's Law
- Why does the M/M/1 model need the utilisation to be strictly below one?
- The state probabilities form a geometric series in rho, and that series only sums to a finite value when rho is less than one. At rho equal to or above one, work arrives at least as fast as it can be served, the queue grows without bound, and no steady-state probabilities or averages exist to report. Chapter 06 · Birth-Death Processes and the M/M/1 Queue
- Why does a single shared queue beat several separate queues with the same servers?
- With separate lines a job can sit behind a busy server while another server has nothing to do, so capacity is wasted. A shared line hands the next job to whichever server frees up first. In the lecture's terminal-room comparison each design has the same per-terminal utilization, yet the mean time in the system with separate queues is two and a half times that of the pooled room. Chapter 07 · Multi-Server Queues and Queueing Networks
- Do operational laws need Poisson arrivals or exponential service times?
- No. They are relationships between averages that were actually measured over an observation window, so they hold for any distribution. The single condition they lean on is job flow balance, meaning arrivals and completions match in the region the law is applied to. Distributional assumptions only return when you want to predict behaviour that was never measured. Chapter 08 · Operational Laws
- Why does a faster processor sometimes fail to raise peak throughput?
- Peak throughput under heavy load is capped at 1/Dmax, the inverse of the largest per-job demand. If the processor is not the device with that largest demand, speeding it up lowers total demand D but leaves Dmax unchanged, so the ceiling stays where it was and only lightly loaded users notice a small improvement. Chapter 09 · Performance Bounds and Bottleneck Analysis
How to prepare for the assessments
Before each analytic lecture, work the matching chapter's example by hand with the page covered, then build your own one-page index listing each law or model beside the measured inputs it needs. Bring that index to both open-book tests and practise choosing the model in the first minute of every question.
Your AI Computer Science tutor for CS5239
Stuck on a hard CS5239 question? Sia is AskSia’s AI Computer Science tutor — ask any CS5239 Performance Analysis of Computer Systems question and get a clear, step-by-step explanation grounded in how the course is actually taught and assessed. Read this whole study guide free, then take your hardest questions to Sia.
