2.3 軟件性能的時空視角

從時空的視角來看，性能是指在完成某項任務時所展示出來的及時性和空間資源的有效性。

性能指標是衡量性能的尺度。從時間的維度來看，性能指標包括響應時間、延時時間等；從空間的維度來看，性能指標包括吞吐量、并發用戶數和資源利用率等，此外，還有故障響應時間指標。故障響應時間是指軟件從出現故障到確認修復前的時間，該指標通常用于反映服務水平。顯然，平均故障響應時間越短，故障對用戶系統的影響越小。

2.3.1 系統性能的時間指標

響應時間指系統對用戶請求做出響應的時間，與人對軟件性能的主觀感受一致。它完整地記錄了軟件處理請求的時間。由于一款軟件通常會提供許多功能，不同功能的處理邏輯也千差萬別，因此不同功能的響應時間也不盡相同，甚至同一功能在不同環境（如輸入的數據不同）下的響應時間也不相同。因此，響應時間通常是指該軟件所有功能的平均響應時間或者所有功能中的最大響應時間。當然，有時候也需要針對每個或每組功能討論其平均響應時間和最大響應時間。

軟件的響應時間是我們所關注的關鍵性能指標，而影響響應時間的主要因素涉及各種各樣的延時，下面介紹兩種延時的抽象模型。

1.排隊延時

負載和響應時間之間的數學關系是眾所周知的。一個稱為M/M/m的排隊模型將響應時間與滿足一組特定需求的系統負載聯系了起來。M/M/m有一個假設，即系統具有“理論上的完美可伸縮性”。盡管這個假設有些過分，但M/M/m在性能方面還是有很多值得我們學習的地方。在低負載時，響應時間基本上與空負載時的響應時間相同。隨著負載的增加，響應時間會逐漸縮短。這種逐漸的退化并沒有造成太大的危害，但是隨著負載持續上升，響應時間開始以一種不再輕微的漸變方式退化。這種退化令人不爽，而且是呈現雙曲線趨勢的。

在M/M/m中，響應時間（r）由兩個部分組成：服務時間（s）和排隊延時（q）。服務時間是任務消耗給定資源的時間，以每個任務執行的時間為單位。排隊延時是指任務排隊等待使用給定資源的時間。排隊延時也可以用每個任務執行的時間來度量，此時指給定任務的響應時間與卸載系統上同一任務的響應時間之間的差異（不要忘記“理論上完美可伸縮性”的假設）。

2.相干延時

相干延時是由于任務的有序性執行造成的時間延遲，無法使用M/M/m排隊模型。這是因為M/M/m假設所有m個服務通道都是并行、同構且獨立的，這意味著M/M/m假設當某用戶在先進先出隊列中等待足夠長的時間，并且前面排隊的所有請求都已經退出服務隊列后，才會輪到該用戶接收服務。然而，相干延時并不遵循這種工作方式。

假設有一個HTML數據輸入表單，其中，Update（更新）按鈕用于執行SQL Update語句，Save（保存）按鈕用于執行SQL commit（提交）語句，用這種方式構建的軟件幾乎可以直接看到性能的糟糕程度。這對于希望更新同一行數據的其他任務來說，帶來的影響可能是毀滅性的。每個任務都必須等待該行的鎖定（在某些系統上，可能是更糟糕的頁鎖定），直到鎖定用戶決定繼續下面的工作并單擊Save按鈕，或者直到數據庫管理員終止用戶的會話。

在這種情況下，任務等待釋放鎖的時間與系統的繁忙程度無關，而是取決于系統各種資源利用以外的隨機因素。這就是為什么永遠不能假設在單元測試環境中執行的性能測試能夠決定是否將新代碼插入生產系統。

2.3.2 軟件性能的空間指標

軟件性能的空間指標包括吞吐量、系統所支持的用戶總數、并發用戶數和資源利用率等。吞吐量是指系統在單位時間內處理請求的數量。對于無并發功能的軟件而言，吞吐量與響應時間呈嚴格的反比關系，實際上，此時的吞吐量就是響應時間的倒數。無并發的軟件都是單機應用的。對于互聯網或者移動互聯網上的產品而言，并發用戶數是指系統可以同時承載的正常使用軟件功能的用戶數量。與吞吐量相比，并發用戶數是一個更直觀但也更籠統的性能指標。資源利用率反映的是在一段時間內資源平均被占用的情況，一個主要的度量指標就是負載，另一個是數據傾斜。

1.負載

許多人不明白，為什么讓一個程序變得更有效率會給系統中的其他程序帶來性能改進，而這些程序與正在修復的程序沒有明顯的關系。其實，這是由于負載對系統的影響。

負載是指由并發任務執行引起的資源競爭，這就是性能測試難以捕捉到生產后期出現的所有性能問題的原因。負載的一個度量指標是利用率。

利用率=使用的資源/指定時間間隔內的資源容量

隨著資源利用率的提高，用戶從該資源請求服務時的響應時間也會增加。這就如同交通非常擁擠時，必然會導致等紅綠燈的時間變長。

軟件運行環境中的CPU在每個時鐘周期內都有固定的指令數量，這就會讓軟件總是以同樣的速度運行，但是響應時間肯定會隨著系統資源使用的增加而受到影響。在分布式系統中，數據在不同空間的存儲位置同樣會對軟件的性能產生影響。

2.數據傾斜

假設有x個數據庫調用，調用操作占用了y秒的響應時間。如果能消除一半的調用量，那么能消除多少不必要的響應時間呢？答案往往出人意料，幾乎從來不是“一半的響應時間”，能消除的響應時間取決于我們可以消除的單個調用的響應時間。不能假設每個調用平均的持續時間為y/x秒，因為語句沒有告訴我們調用的持續時間是一致的。

數據傾斜用于表征具體調用中的不一致性。因為存在數據出現傾斜的可能性，所以無法對軟件的響應時間提供準確預估。在不了解任何有關數據傾斜信息的情況下，可以提供的答案可能是“響應時間在0～y秒之間”。但是，假設有具體的附加信息，就可以對最佳情況和最差情況進行估算。在數據庫應用中，讀寫分離也只是大粒度分隔數據傾斜的一種方式。

2.3.3 系統性能指標的時空關聯

由于時空的內在聯系，系統性能的時空指標往往具有較強的相關性。以吞吐量和響應時間這兩個重要的指標為例，吞吐量和響應時間通常相互關聯，但并不完全相同，真正的關系是微妙而復雜的。

1.并發通信中的吞吐量與響應時間

假設某個基準測試以每秒1000個任務的速度測量了吞吐量，那么用戶的平均響應時間是多少呢？人們很容易認為每個任務的平均響應時間是0.001s，但事實并非如此。如果處理這個吞吐量的系統有1000個并行、獨立且同質的服務通道，那么每個請求可能正好消耗1s。

現在我們知道每個任務的平均響應時間在0～1s之間。然而，不能僅從吞吐量測量中推導出響應時間，必須單獨測量它。當然，有些數學模型可以計算給定吞吐量下的響應時間，但是模型需要更多的輸入，而不僅是吞吐量。

2.計算環境中的吞吐量與響應時間

計算環境展示了吞吐量和響應時間之間的微妙關系。如果需要在單個CPU的計算機上編程以實現每秒100個新任務的吞吐量，假設編寫的新任務在計算機系統上的執行僅需0.001s，那么是否能夠達到所需的吞吐量？如果能夠在0.001s內運行一次任務，那么肯定可以在1s內至少運行100次。例如，如果任務請求被很好地序列化，就可以在一個循環中依次處理這100個任務。

然而，如果每秒100個任務隨機出現在系統上，即100個不同的用戶登錄到單個CPU計算機上，那么會發生什么呢？CPU調度器和序列化資源可能會將吞吐量限制在遠低于每秒100個任務的范圍內，因此不能僅憑對響應時間的度量來推導出吞吐量，還需要進行單獨的測量。

響應時間和吞吐量并不一定相反。要了解這兩者之間的關系，需要同時測量它們。哪一個更重要呢？對于給定的情況，可以從兩個方向上合理地尋找答案。在許多情況下，兩者都需要管理的核心性能指標。例如，系統可能有一個業務需求，要求在99%以上的系統響應，給定任務的響應時間必須小于1s，同時系統必須支持在1s的間隔內持續執行1000個任務。

2.3.4 常見的軟件性能指標

軟件的時空架構決定了軟件性能的時空約束。而軟件時空屬性自身的復雜性與多樣性也導致了軟件性能指標的豐富性。不同的業務系統、子系統乃至功能模型之間都存在著共同的性能指標，如延時、資源利用率等。同時也存在著各自的差異性指標，如前端系統的最大繪制內容（LCP）、累積布局偏移（CLS）等。常見的部分性能指標及其介紹如表2-1所示。

表2-1中涉及的性能指標是一些關鍵指標，尋找各種軟件性能指標的完備集是非常困難的。根據軟件業務需求的多樣性，會產生許多復合指標。有些性能指標可以直接度量，而有些則只能通過度量指標以間接計算的方式得到。很多時候，大家也把度量指標當作性能指標進行討論。