不同視角下的軟體性能與性能名額

對軟體性能最普遍的了解就是軟體處理的及時性。但其實，從不同的系統類型，以及不同的視角去讨論軟體性能，都會有所差別。

文章目錄

• • • 不同類型的系統，軟體性能的關注點各不相同
    • 終端使用者眼中的軟體性能
    • 運維人員眼中的軟體性能
    • 軟體設計開發人員眼中的軟體性能
    • • • 算法設計包含的點：
        • 架構設計包含的内容
        • 性能最佳實踐包括地點
        • 資料庫相關地點
        • 軟體性能的可測試性包含的點
        • 性能測試人員眼中的軟體性能
    • 衡量軟體性能的名額
    • • • 并發使用者數
        • 響應時間
        • 系統吞吐量
      • 并發使用者數、響應事件、系統吞吐量之間的關系

不同類型的系統，軟體性能的關注點各不相同

• Web 類應用和手機端應用，一般以終端使用者感受到的端到端的響應時間來描述系統的能；
• 非互動式的應用，比如典型的電信和銀行背景處理系統，響應時間關注更多的是事件處理的速度，以及機關時間的事件吞吐量。

對同一個系統來說，不同的對象群體對軟體性能的關注點和期望也不完全相同，甚至很多時候是對立的。這裡，不同的對象群體可以分為四大類：終端使用者、系統運維人員、軟體設計開發人員和性能測試人員。

終端使用者眼中的軟體性能

從終端使用者（也就是軟體系統使用者）的次元來講，軟體性能表現為使用者進行業務操作時的主觀響應時間。具體來講就是，從使用者在界面上完成一個操作開始，到系統把本次操作的結果以使用者能察覺的方式展現出來的全部時間。對終端使用者來說，這個時間越短體驗越好。

這個響應時間是終端使用者對系統性能的最直覺印象，包括了系統響應時間和前端展現時間。

• 系統響應時間，反應的是系統能力，又可以進一步細分為應用系統處理時間、資料庫處理時間和網絡傳輸時間等；

• 前端展現時間，取決于使用者端的處理能力

  從這個角度來看，你就可以非常容易了解性能測試為什麼會分為後端（伺服器端）的性能測試和前端（通常是浏覽器端）的性能測試了。

運維人員眼中的軟體性能

除了包括單個使用者的響應時間外，更要關注大量使用者并發通路時的負載，以及可能的更大負載情況下的系統健康狀态、并發處理能力、目前部署的系統容量、可能的系統瓶頸、系統配置層面的調優、資料庫的調優，以及長時間運作穩定性和可擴充性。

大多數情況下，系統運維人員和終端使用者是站在同一條戰線上的，希望系統的響應速度盡可能地快。但，某些情況下他們的意見是對立的，最常見的情況就是，系統運維人員必須在最大并發使用者數和系統響應時間之間進行權衡取舍。比如，當有兩套系統配置方案可以提供以下系統能力的時：

• 配置方案 A 可以提供 100 萬并發通路使用者的能力，此時使用者的登入響應時間是 3 秒；

• 配置方案 B 可以提供 500 萬并發通路使用者的能力，此時使用者的登入響應時間是 8 秒。

  這時，從全局利益最大化角度來看，系統具有更大并發使用者承載能力的價值會更大，是以運維人員一般都會選擇方案 B。

目前，有些系統為了能夠承載更多的并發使用者，往往會犧牲等待時間而引入預期的等待機制。比如，火車票購票網站，就在處理極大并發使用者時采用了排隊機制，以盡可能提高系統容量，但卻增加了使用者實際感受到的響應時間。

軟體設計開發人員眼中的軟體性能

關注的是性能相關的設計和實作細節，這幾乎涵蓋了軟體設計和開發的全過程。

在軟體設計開發人員眼中，軟體性能通常會包含算法設計、架構設計、性能最佳實踐、資料庫相關、軟體性能的可測試性這五大方面。其中，每個方面關注的點，也包括很多。

算法設計包含的點：

• 核心算法的設計與實作是否高效
• 必要時，設計上是否采用 buffer 機制以題号性能，降低 I/O
• 是否存在潛在的記憶體洩漏
• 是否訊在并發環境下的線程安全問題
• 是否存在不合理的線程同步方式
• 是否存在不佳而李的資源競争

架構設計包含的内容

• 站在整體系統的角度，是否可以友善地進行系統容量和性能擴充
• 應用叢集地可擴充是否經過測試和驗證
• 緩存叢集地可擴充性是否經過測驗和驗證
• 資料庫地可擴充性是否經過測試和驗證

性能最佳實踐包括地點

• 代碼是新啊是否遵守開發語言地性能最佳實踐
• 關鍵代碼是否在白盒級别進行測試
• 是否考慮前端性能地優化
• 必要地時候是否采用資料壓縮傳輸
• 對于既要壓縮又要加密地場景，是否采用先壓縮後加密地順序

資料庫相關地點

• 資料庫表設計是否高效
• 是否引入必要地索引
• SQL 語句地執行計劃是否合理
• SQL 語句除了功能是否要考慮性能要求
• 資料庫是否需要引入讀寫分離機制
• 系統冷啟動後，緩存大量不命中地時候，資料庫承載的壓力是否超負荷

軟體性能的可測試性包含的點

• 是否為性能分析（Profiler）提供必要的接口支援
• 是否支援高并發場景次啊的性能打點

• 是否支援全鍊路的性能分析

  需要注意的是，軟體開發人員一般不會關注系統部署級别的性能，比如軟體運作目标作業系統的調優、應用伺服器的參數調優、資料庫的參數調優、網絡環境調優。

系統部署級别的性能測試，目前一般是在系統性能測試階段或者系統容量規劃階段，由性能測試人員、系統架構師，以及資料庫管理者（DBA）協作完成。

性能測試人員眼中的軟體性能

性能測試工程師關注的是算法設計、架構設計、性能最佳實踐、資料庫相關、軟體性能的可測試性這五大方面。

在系統架構師、DBA，以及開發人員的協助下，性能測試人員既要能夠準确把握軟體的性能需求，又要能夠準确定位引起“不好”性能表現的制約因素和根源，并提出相應的解決方案。

常常需要有以下技能：

• 性能需求的總結和抽象能力；
• 根據性能測試目标，精準的性能測試場景設計和計算能力；
• 性能測試場景和性能測試腳本的開發和執行能力；
• 測試性能報告的分析解讀能力；
• 性能瓶頸的快速排查和定位能力；
• 性能測試資料的設計和實作能力；
• 面對網際網路産品，全鍊路壓測的設計與執行能力，能夠和系統架構師一起處理流量标記、影子資料庫等的技術設計能力；
• 深入了解性能測試工具的内部實作原理，當性能測試工具有限制時，可以進行擴充二次開發；
• 極其寬廣的知識面，既要有“面”的知識，比如系統架構、存儲架構、網絡架構等全局的知識，還要有大量“點”的知識積累，比如資料庫 SQL 語句的執行計劃調優、JVM 垃圾回收（GC）機制、多線程常見問題等等。

衡量軟體性能的名額

衡量軟體性能的三個最常用的名額：并發使用者數、響應時間，以及系統吞吐量。

并發使用者數

并發使用者數，是性能需求與測試最常用，也是最重要的名額之一。它包含了業務層面和後端伺服器層面的兩層含義。

• 業務層面的并發使用者數，指的是實際使用系統的使用者總數。但是，單靠這個名額并不能反映系統實際承載的壓力，我們還要結合使用者行為模型才能得到系統實際承載的壓力。
• 後端伺服器層面的并發使用者數，指的是“同時向伺服器發送請求的數量”，直接反映了系統實際承載的壓力。

eg：一個已經投入運作的 ERP 系統，該系統所在企業共有 5000 名員工都擁有賬号，也就是說這個系統有 5000 個潛在使用者。

根據系統日志分析得知，該系統最大線上使用者數是 2500 人，那麼從宏觀角度來看，2500 就是這個系統的最大并發使用者數。但是，2500 這個資料僅僅是說在最高峰時段有 2500 個使用者登入了系統，而伺服器所承受的壓力取決于登入使用者的行為，是以它并不能準确表現伺服器此時此刻正在承受的壓力。

假設在某一時間點上，這 2500 個使用者中，30% 使用者處于頁面浏覽狀态（對伺服器沒有發起請求），20% 使用者在填寫訂單（也沒有對伺服器發起請求），5% 使用者在遞交訂單，15% 使用者在查詢訂單，而另外的 30% 使用者沒有進行任何操作。那麼此時，這 2500 個“并發使用者”中真正對伺服器産生壓力的隻有 500 個使用者（（5%+15%）*2500=500）。

在這個例子中，5000 是最大的“系統潛在使用者數”，2500 是最大的“業務并發使用者數”，500 則是某個時間點上的“實際并發使用者數”。而此時這 500 個使用者同時執行業務操作所實際觸發的伺服器端的所有調用，叫作“伺服器并發請求數”。

從這個例子可以看出，在系統運作期間的某個時間點上，有一個名額叫作“同時向伺服器發送請求的數量”，這個“同時向伺服器發送請求的數量”就是伺服器層面的并發使用者數，這個名額同時取決于業務并發使用者數和使用者行為模式，而且使用者行為模式占的比重較大。

是以，分析得到準确的使用者行為模式，是性能測試中的關鍵一環。但，獲得精準的使用者行為模式，是除了擷取性能需求外，最困難的工作。

目前，擷取使用者行為模式的方法，主要分為兩種：

• 對于已經上線的系統來說，往往采用系統日志分析法擷取使用者行為統計和峰值并發量等重要資訊；
• 而對于未上線的全新系統來說，通常的做法是參考行業中類似系統的統計資訊來模組化，然後分析。

響應時間

“應用系統從請求發出開始，到用戶端接收到最後一個位元組資料所消耗的時間”，是使用者視角軟體性能的主要展現。

響應時間，分為前端展現時間和系統響應時間兩部分。其中，前端時間，取決于用戶端收到伺服器傳回的資料後渲染頁面所消耗的時間；而系統響應時間，又可以進一步劃分為 Web 伺服器時間、應用伺服器時間、資料庫時間，以及各伺服器間通信的網絡時間。

除非是針對前端的性能測試與調優，軟體的性能測試一般更關注伺服器端。但是，伺服器端響應時間的概念非常清晰、直接，就是指從送出請求起到處理完成的時間，沒有二義性；而前端時間的定義，在我看來存在些歧義。

雖然前端時間一定程度上取決于用戶端的處理能力，但是前端開發人員現在還會使用一些程式設計技巧在資料尚未完全接收完成時呈現資料，以減少使用者實際感受到的主觀響應時間。也就是說，我們現在會普遍采用提前渲染技術，使得使用者實際感受到的響應時間通常要小于标準定義的響應時間。

鑒于此，響應時間的标準定義就不盡合理了，尤其是對于“接收到最後一個位元組”。

比如：加載一個網頁時，如果 10 秒後還是白屏，那你一定會感覺很慢、性能無法接受。但是，回想一下你曾經上新浪網的經曆，當加載新浪首頁時，你應該不會感覺速度很慢吧。其實，實際情況是，新浪首頁的加載時間要遠大于 10 秒，隻是新浪采用了資料尚未完全接收完成時進行呈現的技術，大大縮短了使用者主觀感受到的時間，提升了使用者體驗。

是以，嚴格來講，響應時間應該包含兩層含義：技術層面的标準定義和基于使用者主觀感受時間的定義。而在性能測試過程中，我們應該使用哪個層面的含義将取決于性能測試的類型。顯然，對于軟體伺服器端的性能測試肯定要采用标準定義，而對于前端性能評估，則應該采用使用者主觀感受時間的定義。

系統吞吐量

系統吞吐量，是最能直接展現軟體系統負載承受能力的名額。

這裡需要注意的是，所有對吞吐量的讨論都必須以“機關時間”作為基本前提。

吞吐率 = 吞吐量 / 機關時間。

對性能測試而言用“Requests/Second”“Pages/Second”“Bytes/Second”來衡量吞吐量。當然，從業務的角度來講，吞吐量也可以用機關時間的業務處理數量來衡量。以不同方式表達的吞吐量可以說明不同層次的問題。比如：

• “Bytes/Second”和“Pages/Second”表示的吞吐量，主要受網絡設定、伺服器架構、應用伺服器制約；

• “Requests/Second”表示的吞吐量，主要受應用伺服器和應用本身實作的制約。

  雖說吞吐量可以反映伺服器承受負載的情況，但在不同并發使用者數的場景下，即使系統具有相近的吞吐量，但是得到的系統性能瓶頸也會相差甚遠。

比如，某個測試場景中采用 100 個并發使用者，每個使用者每隔 1 秒發出一個 Request，另外一個測試場景采用 1000 個并發使用者，每個使用者每隔 10 秒發出一個 Request。顯然這兩個場景具有相同的吞吐量, 都是 100 Requests/second，但是兩種場景下的系統性能拐點肯定不同。因為，兩個場景所占用的資源是不同的。

這就要求性能測試場景的名額，必然不是單個，需要根據實際情況組合并發使用者數、響應時間這兩個名額。

并發使用者數、響應事件、系統吞吐量之間的關系

了解了概念後以一個日常生活中的體檢為例說明他們之間的關系和限制。假設我們去體檢中心做入職體檢，通常是先去前台等級個人資訊并領取體檢單，然後根據具體的項目依次完成不同科室的檢查。

假設一共有 5 個科室，每個科室有 3 個候診室，通常你會選擇先做排隊人數較少的檢查項目，直至完成 5 個科室的全部檢查，最後離開體檢中心。

現在，我們做個類比：把整個體檢中心想象成一個軟體系統，從你進入體檢中心到完成全部檢查離開所花費的時間就是響應時間，而同時在體檢中心參加體檢的總人數就是并發使用者數，那麼系統吞吐量就可以想象成是機關時間内完成體檢的人數，比如每小時 100 人。

如果你到達體檢中心的時間比較早，這時人還很少，5 個科室都不用排隊，那麼你就能以最短的時間完成體檢。也就是說，當系統的并發使用者數比較少時，響應時間就比較短；但是由于整體的并發使用者數少，是以系統的吞吐量也很低。

從中，我們可以得出這樣的結論：系統并發使用者數少時，系統的吞吐量也低，系統處于空閑狀态，把這個階段就稱為“空閑區間”

如果你到達體檢中心時，這裡的人已經比較多了，隻有部分科室不需要排隊，但好在每個科室都有 3 個候診室同時進行檢查，是以排隊時間不會很長，你還是可以在較短的時間完成體檢。也就是說，當系統的并發使用者數比較多時，響應時間不會增加太多，是以系統的整體吞吐量也随着并發使用者數的變大而變大的。

從中，我們可以得出這樣的結論：當系統整體負載并不是很大時，随着系統并發使用者數的增長，系統的吞吐量也會随之呈線性增長，我們往往把這個階段稱為 “線性增長區間”。

但是，當體檢中心的人越來越多時，每個科室都需要排隊，而且每個科室的隊伍都很長，你每檢查完一個項目都要花很長時間去排隊進行下一個檢查項目。這樣一來，你完成體檢的時間就會明顯變長。也就是說，系統的并發使用者數達到一定規模時，每個使用者的響應時間都會明顯變長，是以系統的整體吞吐量并不會繼續随着并發使用者數的增長而增長。

從中，我們可以得出這樣的結論：随着系統并發使用者數的進一步增長，系統的處理能力逐漸趨于飽和，是以每個使用者的響應時間會逐漸變長。相應地，系統的整體吞吐量并不會随着并發使用者數的增長而繼續呈線性增長。我們往往把這個階段稱為系統的“拐點”。

最糟糕的情況來了，如果人繼續增加，連排隊、站人的地方都沒有了，候診室中檢查完的人出不來，排隊的人又進不去。也就是說，系統的并發使用者數已經突破極限，每個使用者的響應時間變得無限長，是以系統的整體吞吐量變成了零。換言之，此時的系統已經被壓垮了。

從中，我們可以得出這樣的結論：随着系統并發使用者數的增長，系統處理能力達到過飽和狀态。此時，如果繼續增加并發使用者數，最終所有使用者的響應時間會變得無限長。相應地，系統的整體吞吐量會降為零，系統處于被壓垮的狀态。我們往往把這個階段稱為“過飽和區間”。