目前，對軟件性能最普遍的理解就是軟件處理的及時性。但其實，從不同的系統類型，以及不同的視角去討論軟件性能，都會有所區別。
對於不同類型的系統，軟件性能的關注點各不相同，比如：
- Web類應用和手機端應用，一般以終端用戶感受到的端到端的響應時間來描述系統的性能；
- 非交互式的應用，比如典型的電信和銀行後臺處理系統，響應時間關注更多的是事件處理的速度，以及單位時間的事件吞吐量。
這很容易理解。同樣地，對同一個系統來說，不同的對象羣體對軟件性能的關注點和期望也不完全相同，甚至很多時候是對立的。這裏，不同的對象羣體可以分爲四大類：終端用戶、系統運維人員、軟件設計開發人員和性能測試人員。
圖1 衡量軟件性能的四個維度
終端用戶是軟件系統的最終使用者，他們對軟件性能的反饋直接決定了這個系統的應用前景；而，軟件開發人員、運維人員、性能測試人員，對性能測試的關注點則直接決定了一個系統交付到用戶手中的性能。
只有全面瞭解各類羣體對軟件系統的不同需求，才能保證這個系統具有真正高可靠的性能。所以，接下來我會從這四類人的視角和維度去分享軟件性能到底指的是什麼。
終端用戶眼中的軟件性能
從終端用戶（也就是軟件系統使用者）的維度來講，軟件性能表現爲用戶進行業務操作時的主觀響應時間。具體來講就是，從用戶在界面上完成一個操作開始，到系統把本次操作的結果以用戶能察覺的方式展現出來的全部時間。對終端用戶來說，這個時間越短體驗越好。
這個響應時間是終端用戶對系統性能的最直觀印象，包括了系統響應時間和前端展現時間。
- 系統響應時間，反應的是系統能力，又可以進一步細分爲應用系統處理時間、數據庫處理時間和網絡傳輸時間等；
- 前端展現時間，取決於用戶端的處理能力。
從這個角度來看，你就可以非常容易理解性能測試爲什麼會分爲後端（服務器端）的性能測試和前端（通常是瀏覽器端）的性能測試了。
系統運維人員眼中的軟件性能
從軟件系統運維（也就是系統運維人員）的角度，軟件性能除了包括單個用戶的響應時間外，更要關注大量用戶併發訪問時的負載，以及可能的更大負載情況下的系統健康狀態、併發處理能力、當前部署的系統容量、可能的系統瓶頸、系統配置層面的調優、數據庫的調優，以及長時間運行穩定性和可擴展性。
大多數情況下，系統運維人員和終端用戶是站在同一條戰線上的，希望系統的響應速度儘可能地快。但，某些情況下他們的意見是對立的，最常見的情況就是，系統運維人員必須在最大併發用戶數和系統響應時間之間進行權衡取捨。比如，當有兩套系統配置方案可以提供以下系統能力的時：
- 配置方案A可以提供100萬併發訪問用戶的能力，此時用戶的登錄響應時間是3秒；
- 配置方案B可以提供500萬併發訪問用戶的能力，此時用戶的登錄響應時間是8秒。
這時，從全局利益最大化角度來看，系統具有更大併發用戶承載能力的價值會更大，所以運維人員一般都會選擇方案B。
目前，有些系統爲了能夠承載更多的併發用戶，往往會犧牲等待時間而引入預期的等待機制。比如，火車票購票網站，就在處理極大併發用戶時採用了排隊機制，以儘可能提高系統容量，但卻增加了用戶實際感受到的響應時間。
軟件設計開發人員眼中的軟件性能
從軟件系統開發（也就是軟件設計開發人員）的角度來講，軟件性能關注的是性能相關的設計和實現細節，這幾乎涵蓋了軟件設計和開發的全過程。
在大型傳統軟件企業中，軟件性能絕不僅僅是性能測試階段要考慮的問題，而是整個軟件研發生命週期都要考慮的內容，我們往往把圍繞性能相關的活動稱爲“性能工程”（Performance Engineering）。我曾在惠普軟件研發中心的性能測試卓越中心負責這方面的技術工作，所以感受頗深。
在軟件設計開發人員眼中，軟件性能通常會包含算法設計、架構設計、性能最佳實踐、數據庫相關、軟件性能的可測試性這五大方面。其中，每個方面關注的點，也包括很多。
第一，算法設計包含的點：
- 核心算法的設計與實現是否高效；
- 必要時，設計上是否採用buffer機制以提高性能，降低I/O；
- 是否存在潛在的內存泄露；
- 是否存在併發環境下的線程安全問題；
- 是否存在不合理的線程同步方式；
- 是否存在不合理的資源競爭。
第二，架構設計包含的內容：
- 站在整體系統的角度，是否可以方便地進行系統容量和性能擴展；
- 應用集羣的可擴展性是否經過測試和驗證；
- 緩存集羣的可擴展性是否經過測試和驗證；
- 數據庫的可擴展性是否經過測試和驗證。
第三，性能最佳實踐包含的點：
- 代碼實現是否遵守開發語言的性能最佳實踐；
- 關鍵代碼是否在白盒級別進行性能測試；
- 是否考慮前端性能的優化；
- 必要的時候是否採用數據壓縮傳輸；
- 對於既要壓縮又要加密的場景，是否採用先壓縮後加密的順序。
第四，數據庫相關的點：
- 數據庫表設計是否高效；
- 是否引入必要的索引；
- SQL語句的執行計劃是否合理；
- SQL語句除了功能是否要考慮性能要求；
- 數據庫是否需要引入讀寫分離機制；
- 系統冷啓動後，緩存大量不命中的時候，數據庫承載的壓力是否超負荷。
第五，軟件性能的可測試性包含的點：
- 是否爲性能分析（Profiler）提供必要的接口支持；
- 是否支持高併發場景下的性能打點；
- 是否支持全鏈路的性能分析。
需要注意的是，軟件開發人員一般不會關注系統部署級別的性能，比如軟件運行目標操作系統的調優、應用服務器的參數調優、數據庫的參數調優、網絡環境的調優等。
系統部署級別的性能測試，目前一般是在系統性能測試階段或者系統容量規劃階段，由性能測試人員、系統架構師，以及數據庫管理員（DBA）協作完成。
性能測試人員眼中的軟件性能
從性能工程的角度看，性能測試工程師關注的是算法設計、架構設計、性能最佳實踐、數據庫相關、軟件性能的可測試性這五大方面。
在系統架構師、DBA，以及開發人員的協助下，性能測試人員既要能夠準確把握軟件的性能需求，又要能夠準確定位引起“不好”性能表現的制約因素和根源，並提出相應的解決方案。
一個優秀的性能測試工程師，一般需要具有以下技能：
- 性能需求的總結和抽象能力；
- 根據性能測試目標，精準的性能測試場景設計和計算能力；
- 性能測試場景和性能測試腳本的開發和執行能力；
- 測試性能報告的分析解讀能力；
- 性能瓶頸的快速排查和定位能力；
- 性能測試數據的設計和實現能力；
- 面對互聯網產品，全鏈路壓測的設計與執行能力，能夠和系統架構師一起處理流量標記、影子數據庫等的技術設計能力；
- 深入理解性能測試工具的內部實現原理，當性能測試工具有限制時，可以進行擴展二次開發；
- 極其寬廣的知識面，既要有“面”的知識，比如系統架構、存儲架構、網絡架構等全局的知識，還要有大量“點”的知識積累，比如數據庫SQL語句的執行計劃調優、JVM垃圾回收（GC）機制、多線程常見問題等等。
看到如此多的技能要求你可能有點害怕，的確，性能測試的專業性比較強，我經常把優秀的性能工程師比作是優秀的醫生，也是這個原因。你需要在實際項目中積累大量的實際案例，才能慢慢培養所謂的“性能直覺”，從我個人的學習路徑來講也是如此。
天下無難事只怕有心人，所以抓住一切可以充實自己的機會吧，我們終將會破繭成蝶。
這就是終端用戶、系統運維工程師、軟件開發工程師，以及性能測試工程師眼中的性能測試了，至此我們也就非常容易理解，不同的羣體對同一個系統的性能要求爲什麼會如此不同。
現在，我再來和你說說衡量軟件性能的三個最常用的指標：併發用戶數、響應時間，以及系統吞吐量。只要你接觸過性能測試，或者你的團隊開展過性能測試，你都應該聽說這三個指標。但其實很多人對它們的理解還都停留在表面，並沒有深入細緻地考慮過其本質與內涵，這也導致了性能測試很多時候並沒有發揮應有的作用。
因此，接下來我會和你深入地聊聊這三個指標的內涵和外延，幫助你獲得一個全新的認識。
併發用戶數
併發用戶數，是性能需求與測試最常用，也是最重要的指標之一。它包含了業務層面和後端服務器層面的兩層含義。
- 業務層面的併發用戶數，指的是實際使用系統的用戶總數。但是，單靠這個指標並不能反映系統實際承載的壓力，我們還要結合用戶行爲模型才能得到系統實際承載的壓力。
- 後端服務器層面的併發用戶數，指的是“同時向服務器發送請求的數量”，直接反映了系統實際承載的壓力。
爲了讓你更好地理解這兩層含義之間的區別，我們先一起來看一個實例：一個已經投入運行的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秒，只是新浪採用了數據尚未完全接收完成時進行呈現的技術，大大縮短了用戶主觀感受到的時間，提升了用戶體驗。
所以，嚴格來講，響應時間應該包含兩層含義：技術層面的標準定義和基於用戶主觀感受時間的定義。而在性能測試過程中，我們應該使用哪個層面的含義將取決於性能測試的類型。顯然，對於軟件服務器端的性能測試肯定要採用標準定義，而對於前端性能評估，則應該採用用戶主觀感受時間的定義。
當然，我們在前端性能測試中，會利用一些事件的觸發（比如DOM-Load、Page-load等）來客觀地衡量“主觀的前端性能”。這部分內容我會在後面介紹前端性能測試時，和你詳細討論。
系統吞吐量
系統吞吐量，是最能直接體現軟件系統負載承受能力的指標。
這裏需要注意的是，所有對吞吐量的討論都必須以“單位時間”作爲基本前提。其實，我認爲把“Throughput”翻譯成吞吐率更貼切，因爲我們可以這樣理解：吞吐率=吞吐量/單位時間。但既然國內很多資料已經翻譯爲了“吞吐量”，所以通常情況下我們不會刻意去區分吞吐量和吞吐率，統稱爲吞吐量。
對性能測試而言，通常用“Requests/Second”“Pages/Second”“Bytes/Second”來衡量吞吐量。當然，從業務的角度來講，吞吐量也可以用單位時間的業務處理數量來衡量。
以不同方式表達的吞吐量可以說明不同層次的問題。比如：
- “Bytes/Second”和“Pages/Second”表示的吞吐量，主要受網絡設置、服務器架構、應用服務器制約；
- “Requests/Second”表示的吞吐量，主要受應用服務器和應用本身實現的制約。
這裏需要特別注意的是：雖說吞吐量可以反映服務器承受負載的情況，但在不同併發用戶數的場景下，即使系統具有相近的吞吐量，但是得到的系統性能瓶頸也會相差甚遠。
比如，某個測試場景中採用100個併發用戶，每個用戶每隔1秒發出一個Request，另外一個測試場景採用1000個併發用戶，每個用戶每隔10秒發出一個Request。顯然這兩個場景具有相同的吞吐量, 都是100 Requests/second，但是兩種場景下的系統性能拐點肯定不同。因爲，兩個場景所佔用的資源是不同的。
這就要求性能測試場景的指標，必然不是單個，需要根據實際情況組合併發用戶數、響應時間這兩個指標。
總結
作爲性能測試系列的第一篇文章，我和你一起梳理了軟件性能、軟件性能測試相關的知識點，旨在你對加深軟件性能指標的理解，爲後續的性能測試實戰打好基礎。
首先，我從終端用戶、系統運維人員、軟件設計開發人員和性能測試人員，這四個維度介紹了軟件系統的性能到底指的是什麼：
- 終端用戶希望自己的業務操作越快越好；
- 系統運維人員追求系統整體的容量和穩定；
- 開發人員以“性能工程”的視角關注實現過程的性能；
- 性能測試人員需要全盤考量、各個擊破。
然後，我介紹了軟件性能的三個最常用的指標：併發用戶數，響應時間，系統吞吐量：
- 併發用戶數包含不同層面的含義，既可以指實際的併發用戶數，也可以指服務器端的併發數量；
- 響應時間也包含兩層含義，技術層面的標準定義和基於用戶主觀感受時間的定義；
- 系統吞吐量是最能直接體現軟件系統承受負載能力的指標，但也必須和其他指標一起使用才能更好地說明問題。