2.4Performance and Reliability

A "fast system" and a "reliable system" are measured by separate sets of metrics. Speed directly shapes how satisfied users feel, while reliability determines how well the business can keep operating when something fails. Being able to discuss both in numbers lets you participate in design decisions and SLA (service-level agreement) discussions with real grounding.

2.4.1Performance metrics and benchmarks

• Response time is the time from issuing a request until the first response comes back. Turnaround time is the time from issuing a request until all output is fully produced. Online processing tends to emphasize response time, which shapes perceived speed, while batch processing tends to emphasize turnaround time, which reflects when the entire job finishes.
• Throughput is the amount of work a system can process per unit time (e.g., transactions per second). A benchmark is a method of running standardized test programs to objectively compare the performance of multiple systems or configurations. Because catalog specs (clock frequency, etc.) alone cannot correctly capture real-workload performance, benchmark measurement is emphasized in practice.

2.4.2Availability and MTBF/MTTR

• Availability is the fraction of time a system is operating normally. For a series connection (the whole thing works only if both devices are working), availability is the product of each device's availability. For a parallel connection (the whole thing works if at least one device is working), availability is 1 - (product of each device's unavailability). Parallelizing (adding redundancy) is a representative way to raise availability.
• MTBF (Mean Time Between Failures) is the average operating time between one failure and the next; a larger value means the system fails less often. MTTR (Mean Time To Repair) is the average time from a failure until the repair is complete; a smaller value means faster recovery. Availability can also be computed as MTBF / (MTBF + MTTR).

Let us trace an availability calculation with concrete numbers. Connecting device A (availability 0.9) and device B (availability 0.8) in series—where the whole system works only if both are simultaneously normal—gives an overall availability of 0.9 x 0.8 = 0.72. Connecting the same two devices in parallel (the whole works if even one is normal) means the whole thing goes down only if both fail simultaneously, so overall availability becomes 1 - (1-0.9) x (1-0.8) = 1 - 0.1 x 0.2 = 1 - 0.02 = 0.98, a substantial improvement. This shows that to raise reliability, parallelizing (adding redundancy at) the critical point is effective, rather than simply adding more devices in series. That said, the principle that adding devices in series always lowers availability (more factors multiplied together) while adding them in parallel raises it should not be applied mechanically every time a feature is added—what matters in practice is judging whether a given device acts on the system in a series-like or parallel-like way. Availability can also be derived from MTBF and MTTR. If a server has an MTBF of 950 hours and an MTTR of 50 hours, availability = 950 / (950 + 50) = 950 / 1000 = 0.95. This formula shows that raising availability is equally achievable by shortening the repair time (reducing MTTR) as by lengthening the interval between failures (increasing MTBF). Strengthening monitoring or keeping spare parts on hand to shorten MTTR is just as practical a way to raise availability as improving MTBF (making the components themselves more reliable).

2.4.3RASIS and failure-handling design philosophies

• Fault tolerant is a design philosophy that keeps the entire system functioning even when a component fails, by switching to a redundant backup, for example—dual power supplies or disk mirroring. It tolerates the failure itself while aiming to remain outwardly normal.
• Fail-safe is a design philosophy that, when a failure occurs, moves the system to a safe state that minimizes damage—for example, a broken traffic light turns all-red rather than risking a dangerous state where two directions show green simultaneously. Fail-soft is a design philosophy that isolates the failed part and continues operating at reduced capability rather than stopping entirely—for example, an aircraft that loses one engine continues flying on its remaining engines, a form of degraded operation.

2.4.4Section summary

• Response time = until the first response; turnaround time = until all output completes. Throughput is work processed per unit time; benchmarks provide objective comparison
• Series availability = the product; parallel availability = 1 - (product of unavailabilities). Availability = MTBF / (MTBF + MTTR). RASIS = Reliability/Availability/Serviceability/Integrity/Security
• Fault tolerant = keep functioning via redundancy; fail-safe = move to a safe state; fail-soft = keep operating in a degraded form