目前，對軟體性能最普遍的了解就是軟體處理的及時性。但其實，從不同的系統類型，以及不同的視角去讨論軟體性能，都會有所差別。
對于不同類型的系統，軟體性能的關注點各不相同，比如：
- 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，但是兩種場景下的系統性能拐點肯定不同。因為，兩個場景所占用的資源是不同的。
這就要求性能測試場景的名額，必然不是單個，需要根據實際情況組合并發使用者數、響應時間這兩個名額。
總結
作為性能測試系列的第一篇文章，我和你一起梳理了軟體性能、軟體性能測試相關的知識點，旨在你對加深軟體性能名額的了解，為後續的性能測試實戰打好基礎。
首先，我從終端使用者、系統運維人員、軟體設計開發人員和性能測試人員，這四個次元介紹了軟體系統的性能到底指的是什麼：
- 終端使用者希望自己的業務操作越快越好；
- 系統運維人員追求系統整體的容量和穩定；
- 開發人員以“性能工程”的視角關注實作過程的性能；
- 性能測試人員需要全盤考量、各個擊破。
然後，我介紹了軟體性能的三個最常用的名額：并發使用者數，響應時間，系統吞吐量：
- 并發使用者數包含不同層面的含義，既可以指實際的并發使用者數，也可以指伺服器端的并發數量；
- 響應時間也包含兩層含義，技術層面的标準定義和基于使用者主觀感受時間的定義；
- 系統吞吐量是最能直接展現軟體系統承受負載能力的名額，但也必須和其他名額一起使用才能更好地說明問題。