Skip to content

Defining performance terminology

Concept · Chapter 10

Architects need precise terms to specify, measure, and discuss performance. These terms are frequently confused (especially latency vs. response time), so pin them down before optimizing.

TermDefinitionNotes / units
LatencyTime (delay) to send information from source to destination — “time on the wire.”Usually ms. Affected by network hardware, connection type, distance, congestion.
ThroughputWork items per unit time.Network: data moved per time (bps, Mbps, Gbps). App logic: e.g. transactions/second.
BandwidthThe maximum possible throughput for a given logical/physical path.A bit-rate ceiling.
Processing timeTime for the system to process a request, excluding network latency.Sometimes split into server vs. client processing time. Affected by code, external software, hardware.
Response timeTotal time from user request to user receiving the response.= network latency + processing time. Not a synonym for latency.
WorkloadAmount of computational processing a machine has at a given time.Consumes processor capacity. Types: CPU, memory, I/O, database. Track it to predict peak loads.
Utilization% of time a resource is in use vs. total time available.E.g. CPU busy 45s of a 60s window = 75%. Measure CPU, memory, disk. As utilization nears max throughput, response times rise.
  • Latency ≠ response time. Response time bundles both the wire time (latency) and the compute time (processing time).
  • Bandwidth ≠ throughput. Bandwidth is the theoretical ceiling; throughput is what you actually achieve.
  • Last-mile latency: a large share of total latency often occurs between the home/office and the ISP — the first or last few hops can dominate even for cross-country/global traffic.
  • Utilization is an early warning: climbing utilization foreshadows rising response times before hard limits are hit.
  • Software Architect’s Handbook (Packt, 2018), Ch.10 “Defining performance terminology”, pp. 740-747.