Randy Stafford
回應時間的重要性#
**回應時間（response time）**對軟體可用性至關重要。很少有事情比等待軟體回應更令人沮喪，尤其是當我們與軟體的互動涉及反覆的刺激與回應循環時。我們會覺得軟體在浪費我們的時間、影響我們的生產力。
然而，回應時間低落的原因在現代應用程式中常被低估。許多效能管理文獻仍然聚焦於資料結構和演算法——雖然這些在某些情境下確實有影響，但在現代多層企業應用中，它們往往不是效能瓶頸的主因。
IPC 才是關鍵#
當效能出現問題時，作者的經驗是：檢查資料結構和演算法往往不是正確的方向。回應時間主要取決於對某個刺激所觸發的**遠端行程間通訊（remote interprocess communications, IPCs）**數量。
- 雖然可能存在其他局部瓶頸，但遠端 IPC 的數量通常才是主宰因素
- 每次遠端 IPC 都會貢獻不可忽略的延遲，而當它們依序執行時，這些延遲會不斷累積
Ripple Loading 的例子#
一個典型的例子是使用 ORM（Object-Relational Mapping）的應用程式中的 ripple loading：為了建構一個物件圖，需要依序執行許多資料庫查詢。當資料庫客戶端是一個中間層應用伺服器，這些查詢通常在單一執行緒中依序執行。即使每次查詢只需 10 毫秒，一個需要 1,000 次查詢的頁面（並不罕見）至少需要 10 秒的回應時間。
其他例子包括：web service 呼叫、HTTP 請求、分散式物件呼叫、request-reply 訊息傳遞，以及透過自訂網路協定的 data-grid 互動。
減少 IPC 的策略#
有幾個相對簡單且知名的策略可以減少每個刺激的遠端 IPC 數量：
- 精簡原則（parsimony）：優化行程之間的介面，確保只交換必要的資料，以最少的互動量完成任務
- 平行化（parallelization）：盡可能平行執行 IPC，讓整體回應時間主要受最慢的 IPC 影響
- 快取（caching）：快取先前 IPC 的結果，讓後續的 IPC 可以直接從本地快取取得資料
設計應用程式時，務必注意每個刺激觸發的 IPC 數量。在分析效能低落的應用程式時，作者常發現 IPC 與刺激的比率高達數千比一。降低這個比率——無論是透過快取、平行化或其他技術——帶來的效益遠大於改變資料結構或調整排序演算法。