軟件性能的影響因素
（1）硬件設施（部署結構、機器配置）
（2）網絡環境（客戶端帶寬、服務器端帶寬）
（3）操作系統（類型、版本、參數配置）
（4）中間件（類型、版本、參數配置）
（5）應用程序（性能）
（6）並發用戶數（系統當前訪問狀態）
（7）客戶端
（8）數據服務器
（9）編程語言、程序實現方式、算法
性能測試最基本要考慮以下幾點
1、時間特性，主要指的是軟件產品的事務響應時間（用戶發出請求到收到應答的這段時間）
2、資源利用率，包括：cpu、內存、網絡、硬盤、虛擬內存（如Java虛擬機）
3、服務器可靠性，指服務器能在相對高負載情況下持續的運行
4、可配置優化性，指服務器配置優化、業務邏輯優化、代碼優化等
檢查系統是否滿足需求規格說明書中規定的性能，通常表現在以下幾個方面：
1、對資源利用（包括：cpu、內存、網絡、硬盤、虛擬內存（如Java虛擬機）等）進行的精確度量；
2、對執行間隔；
3、日志事件（如中斷，報錯）
4、響應時間
5、吞吐量（TPS）
6、輔助存儲區（例如緩沖區、工作區的大小等）
7、處理精度等進行的監測
在實際工作中我們經常會對兩種類型軟件進行測試：bs和cs，這兩方面的性能指標一般需要哪些內容呢？
bs結構程序一般會關注的通用指標如下（簡）：
Web服務器測試指標：
* Avg Rps: 平均每秒鍾響應次數=總請求時間 / 秒數；
* Avg time to last byte per terstion （mstes）：平均每秒業務腳本的迭代次數，有人會把這兩者混淆；
* Successful Rounds：成功的請求；
* Failed Rounds ：失敗的請求；
* Successful Hits ：成功的點擊次數；
* Failed Hits ：失敗的點擊次數；
* Hits Per Second ：每秒點擊次數；
* Successful Hits Per Second ：每秒成功的點擊次數；
* Failed Hits Per Second ：每秒失敗的點擊次數；
* Attempted Connections ：嘗試鏈接數；
CS結構程序，由於一般軟件后台通常為數據庫，所以我們更注重數據庫的測試指標：
* User 0 Connections ：用戶連接數，也就是數據庫的連接數量；
* Number of deadlocks：數據庫死鎖；
* Buffer Cache hit ：數據庫Cache的命中情況
當然，在實際中我們還會察看多用戶測試情況下的內存，CPU，系統資源調用情況。這些指標其實是引申出來性能測試中的一種：競爭測試。什么是競爭測試，軟件競爭使用各種資源（數據紀錄，內存等），看他與其他相關系統對資源的爭奪能力。
我們知道軟件架構在實際測試中制約着測試策略和工具的選擇。如何選擇性能測試策略是我們在實際工作中需要了解的。一般軟件可以按照系統架構分成幾種類型：
c/s
client/Server 客戶端/服務器架構
基於客戶端/服務器的三層架構
基於客戶端/服務器的分布式架構
b/s
基於瀏覽器/Web服務器的三層架構
基於中間件應用服務器的三層架構l
基於Web服務器和中間件的多層架構l
性能指標的兩個方面
外部指標|系統指標（與用戶場景和需求相關指標）
從外部看，性能測試主要關注如下四個指標
- 吞吐量：每秒鍾系統能夠處理客戶的請求數、任務數，其直接體現系統的承載的能力。
- 並發用戶數：同一時刻與服務器進行數據交互的所有用戶數量；
- 響應時間：服務處理一個請求或一個任務的耗時。
- 錯誤率：一批請求中結果出錯的請求所占比例。
響應時間
從單個請求來看就是服務響應一次請求的花費的時間。但是在性能測試中，單個請求的響應時間並沒有什么參考價值，通常考慮的是完成所有請求的平均響應時間及中位數時間。
平均響應時間很好理解，就是完成請求花費的總時間/完成的請求總數。但是平均響應時間有一點不靠譜，因為系統的運行並不是平穩平滑的，如果某幾個請求的時間超短或者超長就會導致平均數偏離很多。因此有時候我們會用中位數響應時間。
所謂中位數的意思就是把將一組數據按大小順序排列，處在最中間位置的一個數叫做這組數據的中位數 ，這意味着至少有50%的數據低於或高於這個中位數。當然，最為正確的統計做法是用百分比分布統計。也就是英文中的TP – Top Percentile ，TP50的意思在，50%的請求都小於某個值，TP90表示90%的請求小於某個時間。
響應時間的指標取決於具體的服務。如智能提示一類的服務，返回的數據有效周期短（用戶多輸入一個字母就需要重新請求），對實時性要求比較高，響應時間的上限一般在100ms以內。而導航一類的服務，由於返回結果的使用周期比較長（整個導航過程中），響應時間的上限一般在2-5s。
決定系統響應時間要素
我們做項目要排計划，可以多人同時並發做多項任務，也可以一個人或者多個人串行工作，始終會有一條關鍵路徑，這條路徑就是項目的工期。
系統一次調用的響應時間跟項目計划一樣，也有一條關鍵路徑，這個關鍵路徑是就是系統響應時間；
關鍵路徑是由CPU運算、IO、外部系統響應等等組成。
計算公式
1、響應時間：對一個請求做出響應所需要的時間
網絡傳輸時間：N1+N2+N3+N4
應用服務器處理時間：A1+A3
數據庫服務器處理時間：A2
響應時間=網絡響應時間+應用程序響應時間=（N1+N2+N3+N4）+(A1+A2+A3)
2、平均響應時間：所有請求花費的平均時間
系統處理事務的響應時間的平均值。事務的響應時間是從客戶端提交訪問請求到客戶端接收到服務器響應所消耗的時間。對於系統快速響應類頁面，一般響應時間為3秒左右。
如：如果有100個請求，其中 98 個耗時為 1ms，其他兩個為 100ms
平均響應時間： (98 * 1 + 2 * 100) / 100.0 = 2.98ms，但是，2.98ms並不能反映服務器的整體效率，因為98個請求耗時才1ms，引申出百分位數
百分位數：以響應時間為例，指的是 99% 的請求響應時間，都處在這個值以下，更能體現整體效率。
注：（一般響應時間在3s內，用戶會感覺比較滿意。在3s~8s之間用戶勉強能接受，大於8s用戶就可能無法接受，從而刷新頁面或者離開，僅供參考）
響應時間與負載對應關系
圖中拐點說明：
（1）響應時間突然增加
（2）意味着系統的一種或多種資源利用達到的極限
（3）通常可以利用拐點來進行性能測試分析與定位
並發用戶數
一、首先涉及到並發用戶數可以從以下幾個方面去做數據判斷。
1.系統用戶數
2.在線用戶數
3.並發用戶數
二、三者之間的關系
1.在線用戶數的預估可以采取20%的系統用戶數。例如某個系統在系統用戶數有1000，則同時在線用戶數據有可能達到200，或者預估200做參考。
2.在線用戶數和並發用戶數又存在着關系。即：平均並發用戶數為:c=NL/T L為在線時長，T為考核時長。例如:考核時長為1天，即8小時，但是用戶平均在線時長為2小時，則c=n*2/8 n為登錄系統的用戶數，L為登錄的時常。例如:一個系統有400個用戶登錄，然后每個用戶登錄大概停留2小時，則以一天8小時考核，算平均並發用戶則為:c=400*2/8
並發主要是針對服務器而言，在同一時刻與服務器進行交互（指向服務器發出請求）的在線用戶數。
（1）並發用戶數：某一物理時刻同時向系統提交請求的用戶數，提交的請求可能是同一個場景或功能，也可以是不同場景或功能。
（2）在線用戶數：某段時間內訪問系統的用戶數，這些用戶並不一定同時向系統提交請求。如多個用戶在瀏覽網頁，但沒有對同時對服務器進行數據請求，需要與並發用戶數區分開。
（3）系統用戶數：系統注冊的總用戶數據
三者之間的關系：系統用戶數 >= 在線用戶數 >= 並發用戶數
同時在線用戶數：在一定的時間范圍內，最大的同時在線用戶數量。
同時在線用戶數=每秒請求數RPS（吞吐量）+並發連接數+平均用戶思考時間
平均並發用戶數的計算：C=nL / T
其中C是平均的並發用戶數，n是平均每天訪問用戶數（login session），L是一天內用戶從登錄到退出的平均時間（login session的平均時間），T是考察時間長度（一天內多長時間有用戶使用系統）
並發用戶數峰值計算：C^約等於C + 3*根號C 也是峰值C1,即最大並發數，計算公式C1=C+³√C
其中C^是並發用戶峰值，C是平均並發用戶數，該公式遵循泊松分布理論。
注：理解最佳並發用戶數和最大並發用戶數
看了《LoadRunner沒有告訴你的》之理發店模式，對最佳並發用戶數和最大的並發用戶數的理解小小整理了一下。
所謂的理發店模式，簡單地闡述一下，一個理發店有3個理發師，當同時來理發店的客戶有3個的時候，那么理發師的資源能夠有效地利用，這時3個用戶數即為最佳的並發用戶數；當理發店來了9個客戶的時候，3個客戶理發，而6個用戶在等待，3個客戶的等待時間為1個小時，另外的3個客戶的等待時間為2小時，客戶的最大忍受時間為3小時包括理發的1個小時，所以6個客戶的等待時間都在客戶的可以承受范圍內，故9個客戶是該理發店的最大並發用戶數。
吞吐量
我把吞吐量定義為“單位時間內系統處理的客戶請求的數量”（ 吞吐量表示單位時間內能夠完成的事務數量，因此也被稱為每秒事務數（Transaction Per Second），計算方式是完成的事務數除以時間。），直接體現軟件系統的性能承載能力，對於交互式應用系統來說、吞吐量反映的是服務器承受的壓力、在容量規划的測試中、吞吐量是一個重要指標、它不但反映在中間件、數據庫上、更加體現在硬件上。
吞吐量的指標受到響應時間、服務器軟硬件配置、網絡狀態等多方面因素影響。
- 吞吐量越大，響應時間越長。
- 服務器硬件配置越高，吞吐量越大。
- 網絡越差，吞吐量越小。
在低吞吐量下的響應時間的均值、分布比較穩定，不會產生太大的波動。在高吞吐量下，響應時間會隨着吞吐量的增長而增長，增長的趨勢可能是線性的，也可能接近指數的。當吞吐量接近系統的峰值時，響應時間會出現激增。
系統吞度量要素
一個系統的吞度量（承壓能力）與request對CPU的消耗、外部接口、IO等等緊密關聯。單個reqeust 對CPU消耗越高，外部系統接口、IO影響速度越慢，系統吞吐能力越低，反之越高。
系統吞吐量幾個重要參數：QPS（TPS）、並發數、響應時間
QPS(每秒請求數)（TPS （Transaction Per Second）每秒事務數）：每秒鍾系統處理的request/事務數量，它是衡量系統處理能力的重要指標；
並發數：系統同時處理的request/事務數
響應時間：一般取平均響應時間
理解了上面三個要素的意義之后，就能推算出它們之間的關系：QPS（TPS）= 並發數/平均響應時間
一個系統吞吐量通常由QPS（TPS）、並發數兩個因素決定，每套系統這兩個值都有一個相對極限值，在應用場景訪問壓力下，只要某一項達到系統最高值，系統的吞吐量就上不去了，如果壓力繼續增大，系統的吞吐量反而會下降，原因是系統超負荷工作，上下文切換、內存等等其它消耗導致系統性能下降。
系統吞吐量評估
我們在做系統設計的時候就需要考慮CPU運算、IO、外部系統響應因素造成的影響以及對系統性能的初步預估。而通常情況下，我們面對需求，我們評估出來的QPS、並發數之外，還有另外一個維度：日頁面流量PV。
PV：訪問一個URL，產生一個PV（Page View，頁面訪問量），每日每個網站的總PV量是形容一個 網站規模的重要指標。
UV：作為一個獨立的用戶，訪問站點的所有頁面均算作一個UV（Unique Visitor，用戶訪問）
通過觀察系統的訪問日志發現，在用戶量很大的情況下，各個時間周期內的同一時間段的訪問流量幾乎一樣。只要能拿到日流量圖和QPS我們就可以推算日流量。
通常的技術方法：
1. 找出系統的最高TPS和日PV，這兩個要素有相對比較穩定的關系（除了放假、季節性因素影響之外）
2. 通過壓力測試或者經驗預估，得出最高TPS，然后跟進1的關系，計算出系統最高的日吞吐量。
無論有無思考時間（T_think），測試所得的TPS值和並發虛擬用戶數(U_concurrent)、Loadrunner讀取的交易響應時間（T_response）之間有以下關系（穩定運行情況下）：TPS=U_concurrent / (T_response+T_think)。
並發數、QPS、平均響應時間三者之間關系
X軸代表並發用戶數，Y軸代表資源利用率、吞吐量、響應時間。
X軸與Y軸區域從左往右分別是輕壓力區、重壓力區、拐點區。
隨着並發用戶數的增加，在輕壓力區的響應時間變化不大，比較平緩，進入重壓力區后呈現增長的趨勢，最后進入拐點區后傾斜率增大，響應時間急劇增加。接着看吞吐量，隨着並發用戶數的增加，吞吐量增加，進入重壓力區后逐步平穩，到達拐點區后急劇下降，說明系統已經達到了處理極限，有點要扛不住的感覺。
同理，隨着並發用戶數的增加，資源利用率逐步上升，最后達到飽和狀態。
最后，把所有指標融合到一起來分析，隨着並發用戶數的增加，吞吐量與資源利用率增加，說明系統在積極處理，所以響應時間增加得並不明顯，處於比較好的狀態。但隨着並發用戶數的持續增加，壓力也在持續加大，吞吐量與資源利用率都達到了飽和，隨后吞吐量急劇下降，造成響應時間急劇增長。輕壓力區與重壓力區的交界點是系統的最佳並發用戶數，因為各種資源都利用充分，響應也很快；而重壓力區與拐點區的交界點就是系統的最大並發 用戶數，因為超過這個點，系統性能將會急劇下降甚至崩潰。
Light Load（較輕壓力）-----最佳用戶數（資源利用最高）---（較重壓力，系統可以持續工作，但用戶等待時間較長，滿意度會下降）-----Heavy Load-------最大並發用戶數--------Buckle Zone（用戶無法忍受而放棄請求）
最佳並發用戶數：當系統的負載等於最佳並發用戶數時，系統的整體效率最高，沒有資源被浪費，用戶也不需要等待
最大並發用戶數：系統的負載一直持續，有些用戶在處理而有的用戶在自己最大的等待時間內等待的時候
我們需要保證的是：
（1）最佳並發用戶數需大於系統的平均負載
（2）系統的最大並發用戶數要大於系統需要承受的峰值負載
怎么理解這兩句話呢？
（1）系統的平均負載：在特定的時間內，系統正在處理的用戶數和等待處理的用戶數的總和
如果系統的平均負載大於最佳並發用戶數，則用戶的滿意度會下降，所以我們需要保證系統的平均負載小於或者等於最佳並發用戶數
（2）峰值：指的是系統的最大能承受的用戶數的極值
只有最大並發用戶數大於系統所能承受的峰值負載，才不會造成等待空間資源的浪費，導致系統的效率低下
計算公式
指單位時間內系統處理用戶的請求數
從業務角度看，吞吐量可以用：請求數/秒、頁面數/秒、人數/天或處理業務數/小時等單位來衡量
從網絡角度看，吞吐量可以用：字節/秒來衡量
對於交互式應用來說，吞吐量指標反映的是服務器承受的壓力，他能夠說明系統的負載能力
以不同方式表達的吞吐量可以說明不同層次的問題，例如，以字節數/秒方式可以表示數要受網絡基礎設施、服務器架構、應用服務器制約等方面的瓶頸；已請求數/秒的方式表示主要是受應用服務器和應用代碼的制約體現出的瓶頸。
當沒有遇到性能瓶頸的時候，吞吐量與虛擬用戶數之間存在一定的聯系，可以采用以下公式計算：F=VU * R /T
其中F為吞吐量，VU表示虛擬用戶個數，R表示每個虛擬用戶發出的請求數，T表示性能測試所用的時間
吞吐量與負載對應關系
圖中拐點說明：
（1）吞吐量逐漸達到飽和
（2）意味着系統的一種或多種資源利用達到的極限
（3）通常可以利用拐點來進行性能測試分析與定位
錯誤率
超時錯誤率：主要指事務由於超時或系統內部其它錯誤導致失敗占總事務的比率。
錯誤率和服務的具體實現有關。通常情況下，由於網絡超時等外部原因造成的錯誤比例不應超過5%%，由於服務本身導致的錯誤率不應超過1% 。
內部指標|資源指標（與硬件資源消耗相關指標）
資源利用率：
資源利用率指的是對不同系統資源的使用程度，一般使用“資源實際使用/總的資源可用量”形成資源利用率。例如服務器的 CPU 利用率、磁盤利用率等。資源利用率是分析系統性能指標進而改善性能的主要依據，因此，它是 Web 性能測試工作的重點。資源利用率主要針對 Web 服務器、操作系統、數據庫服務器、網絡等，是測試和分析瓶頸的主要參數。在性能測試中，要根據需要采集具體的資源利用率參數來進行分析。
從服務器的角度看，性能測試主要關注CPU、內存、服務器負載、網絡、磁盤IO等
注：PR數值越小，其進程優先級越高，就優先被執行。
TIME+表示的是這個進程或則命令持續在線活躍了多長時間。
1.硬件性能指標：CPU，內存Memory，磁盤I/O（Disk I/O），網絡I/O（Network I/O）
CPU：主要解釋計算機指令以及處理計算機軟件中的數據
Linux系統中top命令查看CPU的使用率
CPU的利用率（<=75%）有：user（用戶使用）,sys（系統調用<=30%）,wait（等待<=5%），idle（空閑）
當user消耗高時，通過top命令查看哪個用戶進程占用cpu的使用
user消耗過高的原因可能有:
（1）代碼問題。如代碼中耗時循環中不加sleep，即例如while的死循環中，沒有加sleep時間，導致沒有空余的時間將cpu的控制權給其他的進程，一直陷入該死循環中，cpu得不到休息，所以usr的消耗過高，則cpu的消耗高
（2）gc頻繁。gc則為垃圾回收，由於垃圾回收也是需要大量的計算，也消耗cpu，所以當gc頻繁時也導致usr用戶空間的消耗也過高，cpu消耗過高
當sys消耗高時，通過top命令查看系統調用資源的情況
sys消耗過高的原因可能有：
（1）上下文切換頻繁。上下文切換發生的情況有：中斷處理，多任務處理，用戶狀態改變。
中斷處理，當cpu停止處理當前的進程轉而處理中斷請求的進程時發生上下文切換。多任務處理則為有多個進程請求cpu的處理，進程的數量多於cpu的核數，則分配進程時間片，根據時間片處理進程，意味着會強制停止一個進程而去處理另一個進程，形成頻繁的上下文切換。用戶狀態改變則為user狀態與sys狀態的改變。
wait較高時，即等待的進程占比高則可以考慮是否磁盤讀寫，磁盤瓶頸問題， 等待的進程較多時，cpu無論如何切換都是切換到等待的進程，導致cpu一直在頻繁切換等待的線程而利用率較低
內存：與cpu溝通的橋梁，計算機中所有程序的運行都在內存中進行，內存分為物理內存、頁面交換（Paging），SWAP內存（虛擬內存）
頁面交換：當物理內存即實際的內存滿了的時候，將物理內存中不常用的進程調出存儲到虛擬內存中，以緩解物理內存空間的壓力，所以當物理內存與虛擬內存的數據交換頻繁的時候，這時候就要關注下內存的性能情況。
SWAP內存：為進程分配虛擬的內存空間，即調用硬盤的空間作為內存使用。
內存的性能分析是又可用內存與頁面交換來分析的，可用內存使用占70%-80%為上限，當超出這個數值，內存性能情況就比較危險，而且即使可用內存使用不超過80%的數值時，頁面交換比較頻繁時，也是要關注下內存情
一般物理內存即使是滿內存也不能代表內存出現問題，主要是看虛擬內存swap，虛擬內存應該<=70%，大於則可以考慮是否內存問題或者內存泄漏
磁盤吞吐量，指單位時間內通過磁盤的數據量。主要關注磁盤的繁忙率，如果高於70%，則磁盤瓶頸
網絡吞吐量，指單位時間內通過網絡的數據量，當吞吐量大於網路設備或鏈路最大傳輸能力，即帶寬時，則應該考慮升級網絡設備或者增加帶寬，Linux命令netstate
網絡IO也有可能出現終止連接失敗。例如當服務端出現大量的TIME_WAIT，見以下TCP終止連接的第4個步驟，在主動發起關閉連接方接收到結束符FIN時狀態變為TIME_WAIT,這時在服務端發現大量的TIME_WAIT,意味着關閉連接是由服務端發起的。
常用的三個狀態是：ESTABLISHED 表示正在通信，TIME_WAIT 表示主動關閉，CLOSE_WAIT 表示被動關閉。
問？什么情況是由服務端發起關閉連接？答：在用戶端的應用程序忘記關閉連接
另外如果在服務端發現大量狀態CLOSE_WAIT,則說明第二次關閉回不去，也就是TCP關閉連接的第三個步驟沒有執行，停留在CLOSE_WAIT的狀態，瀏覽器如果這時發起請求則會返回超時連接，因為服務端這邊一直無法進行第二次關閉，將結束符返回去給用戶端。
注：普及TCP連接的三次握手，終止連接的四次握手
TCP三次握手連接：
(1)用戶端發送SYN給服務器，用戶端的狀態為SYN_SEND
(2)服務端接收到后發送ACK給用戶端，服務端的狀態為SYN_RECV
(3)用戶端接收到服務端發送過來的后發送了ACK給服務端，用戶端的狀態變為Estabilished
TCP終止連接：
(1)用戶端的應用主動發起關閉連接，即應用調用close發送FIN給服務端
(2)服務端接收到FIN后發送ACK給用戶端，服務端的狀態變為CLOSE_WAIT
(3)服務端發送ACK給用戶端的同時也將FIN作為一個文件結束符傳遞給接收端應用程序
(4)用戶端的應用程序接收到FIN后將調用close關閉它的套接字，確認FIN，這時用戶端的狀態變為TIME_WAIT
(5)用戶端發送ACK回執給服務端，連接終止
2.中間件：常用的中間件例如web服務器Tomcat,Weblogic web服務器，JVM（java虛擬機），ThreadPool線程池，JDBC數據驅動
注：http服務器和web服務器與應用服務器的差別是一個存儲靜態網頁的服務器，一個是存儲css，js等動態加載網頁的服務器，而tomcat則屬於應用服務器
注：對中間件例如對服務器的性能測試，需要將監控的jmeter-server的文件下載在服務端上，然后開啟即可監控被測服務器的性能，或者將監控的軟件下載在被測服務器上，遠程啟動監控軟件等
3.數據庫指標
應關注SQL，吞吐量，緩存命中率，連接數等，則是關注sql語句執行時間，以微妙為單位，吞吐量TPS，緩存命中率應>=95%
注：對數據庫的性能測試通過jemter利用批量的sql語句對數據庫進行操作，從而測試數據庫的性能，前提是需要將jdbc的驅動加載在測試計划添加的驅動文件中，然后添加jdbc的前置處理器和jdbc的請求sample。
4.JVM，java虛擬機，為使java的代碼可以編譯運行在不同的平台上順暢，仿真模擬各種計算機來實現
GC：自動內存管理程序，被引用的對象保存在內存中，當對象不被引用時則釋放。關注的參數有Full GC完全java虛擬機垃圾部分回收頻率
5.前端指標
前端應該關注頁面展示，即首次顯示時間，頁面數量，頁面大小，網絡startRender，firstRender等
注：關注前端的性能與后端的性能的不同點在於，前端是每個用戶的直觀的感受，以及前端頁面的加載元素耗費時間給予用戶的感受，而后端的性能關注點在於多用戶使用系統時，服務器是否能夠承受或者服務器的處理能力如何，能否以較好的響應時間響應。
6.Load：系統平均負載，特定時間間隔內運行進程數，Load與cpu核數一致
CPU
CPU使用率：
指用戶進程與系統進程消耗的CPU時間百分比，長時間情況下，一般可接受上限不超過85%。
后台服務的所有指令和數據處理都是由CPU負責，服務對CPU的利用率對服務的性能起着決定性的作用。
Linux系統的CPU主要有如下幾個維度的統計數據：
us：用戶態使用的cpu時間百分比
sy：系統態使用的cpu時間百分比
ni：用做nice加權的進程分配的用戶態cpu時間百分比
id：空閑的cpu時間百分比
wa：cpu等待IO完成時間百分比
hi：硬中斷消耗時間百分比
si：軟中斷消耗時間百分比
下圖是線上開放平台轉發服務某台服務器上top命令的輸出，下面以這個服務為例對CPU各項指標進行說明
us & sy：大部分后台服務使用的CPU時間片中us和sy的占用比例是最高的。同時這兩個指標又是互相影響的，us的比例高了，sy的比例就低，反之亦然。通常sy比例過高意味着被測服務在用戶態和系統態之間切換比較頻繁，此時系統整體性能會有一定下降。另外，在使用多核CPU的服務器上，CPU 0負責CPU各核間的調度，CPU 0上的使用率過高會導致其他CPU核心之間的調度效率變低。因此測試過程中CPU 0需要重點關注。
ni：每個Linux進程都有個優先級，優先級高的進程有優先執行的權利，這個叫做pri。進程除了優先級外，還有個優先級的修正值。這個修正值就叫做進程的nice值。一般來說，被測服務和服務器整體的ni值不會很高。如果測試過程中ni的值比較高，需要從服務器Linux系統配置、被測服務運行參數查找原因
id：線上服務運行過程中，需要保留一定的id冗余來應對突發的流量激增。在性能測試過程中，如果id一直很低，吞吐量上不去，需要檢查被測服務線程/進程配置、服務器系統配置等。
wa：磁盤、網絡等IO操作會導致CPU的wa指標提高。通常情況下，網絡IO占用的wa資源不會很高，而頻繁的磁盤讀寫會導致wa激增。如果被測服務不是IO密集型的服務，那需要檢查被測服務的日志量、數據載入頻率等。
hi & si：硬中斷是外設對CPU的中斷，即外圍硬件發給CPU或者內存的異步信號就是硬中斷信號；軟中斷由軟件本身發給操作系統內核的中斷信號。通常是由硬中斷處理程序或進程調度程序對操作系統內核的中斷，也就是我們常說的系統調用(System Call)。在性能測試過程中，hi會有一定的CPU占用率，但不會太高。對於IO密集型的服務，si的CPU占用率會高一些。
內存
內存利用率：
內存利用率=（1-空閑內存/總內存大小）*100%，一般至少有10%可用內存，內存使用率可接受上限為85%。
性能測試過程中對內存監控的主要目的是檢查被測服務所占用內存的波動情況。
在Linux系統中有多個命令可以獲取指定進程的內存使用情況，最常用的是top命令，如下圖所示
其中
VIRT：進程所使用的虛擬內存的總數。它包括所有的代碼，數據和共享庫，加上已換出的頁面，所有已申請的總內存空間
RES：進程正在使用的沒有交換的物理內存（棧、堆），申請內存后該內存段已被重新賦值
SHR：進程使用共享內存的總數。該數值只是反映可能與其它進程共享的內存，不代表這段內存當前正被其他進程使用
SWAP：進程使用的虛擬內存中被換出的大小，交換的是已經申請，但沒有使用的空間，包括（棧、堆、共享內存）
DATA：進程除可執行代碼以外的物理內存總量，即進程棧、堆申請的總空間
從上面的解釋可以看出，測試過程中主要監控RES和VIRT，對於使用了共享內存的多進程架構服務，還需要監控SHR。
LOAD（服務器負載）
Linux的系統負載指運行隊列的平均長度，也就是等待CPU的平均進程數
從服務器負載的定義可以看出，服務器運行最理想的狀態是所有CPU核心的運行隊列都為1，即所有活動進程都在運行，沒有等待。這種狀態下服務器運行在負載閾值下。
通常情況下，按照經驗值，服務器的負載應位於閾值的70%~80%，這樣既能利用服務器大部分性能，又留有一定的性能冗余應對流量增長。
Linux提供了很多查看系統負載的命令，最常用的是top和uptime
top和uptime針對負載的輸出內容相同，都是系統最近1分鍾、5分鍾、15分鍾的負載均值
Uptime命令結果的每一列的含義如下：
“當前時間 系統運行時長 登錄的用戶數最 近1分鍾、5分鍾、15分鍾的平均負載”
查看系統負載閾值的命令如下，下方是查看CPU每個核心的使用情況：
在性能測試過程中，系統負載是評價整個系統運行狀況最重要的指標之一。通常情況下，壓力測試時系統負載應接近但不能超過閾值，並發測試時的系統負載最高不能超過閾值的80%，穩定性測試時，系統負載應在閾值的50%左右。
網絡
網絡帶寬：
一般使用計數器Bytes Total/sec來度量，Bytes Total/sec表示為發送和接收字節的速率，包括幀字符在內。判斷網絡連接速度是否是瓶頸，可以用該計數器的值和目前網絡的帶寬比較。
性能測試中網絡監控主要包括網絡流量、網絡連接狀態的監控。
網絡流量監控
可以使用nethogs命令。該命令與top類似，是一個實時交互的命令，運行界面如下
在后台服務性能測試中，對於返回文本結果的服務，並不需要太多關注在流量方面。
網絡連接狀態監控
性能測試中對網絡的監控主要是監控網絡連接狀態的變化和異常。對於使用TCP協議的服務，需要監控服務已建立連接的變化情況（即ESTABLISHED狀態的TCP連接）。對於HTTP協議的服務，需要監控被測服務對應進程的網絡緩沖區的狀態、TIME_WAIT狀態的連接數等。Linux自帶的很多命令如netstat、ss都支持如上功能。下圖是netstat對指定pid進程的監控結果
磁盤IO
磁盤主要用於存取數據，因此當說到IO操作的時候，就會存在兩種相對應的操作，存數據的時候對應的是寫IO操作，取數據的時候對應的是讀IO操作，一般使用% Disk Time（磁盤用於讀寫操作所占用的時間百分比）度量磁盤讀寫性能。
性能測試過程中，如果被測服務對磁盤讀寫過於頻繁，會導致大量請求處於IO等待的狀態，系統負載升高，響應時間變長，吞吐量下降。
Linux下可以用iostat命令來監控磁盤狀態，如下圖
tps：該設備每秒的傳輸次數。“一次傳輸”意思是“一次I/O請求”。多個邏輯請求可能會被合並為“一次I/O請求”。“一次傳輸”請求的大小是未知的
kB_read/s：每秒從設備（driveexpressed）讀取的數據量，單位為Kilobytes
kB_wrtn/s：每秒向設備（driveexpressed）寫入的數據量，單位為Kilobytes
kB_read：讀取的總數據量，單位為Kilobytes
kB_wrtn：寫入的總數量數據量，單位為Kilobytes
從iostat的輸出中，能夠獲得系統運行最基本的統計數據。但對於性能測試來說，這些數據不能提供更多的信息。需要加上-x參數
rrqm/s：每秒這個設備相關的讀取請求有多少被合並了（當系統調用需要讀取數據的時候，VFS將請求發到各個FS，如果FS發現不同的讀取請求讀取的是相同Block的數據，FS會將這個請求合並Merge）
wrqm/s：每秒這個設備相關的寫入請求有多少被Merge了
await：每一個IO請求的處理的平均時間（單位是毫秒）
%util：在統計時間內所有處理IO時間，除以總共統計時間。例如，如果統計間隔1秒，該設備有0.8秒在處理IO，而0.2秒閑置，那么該設備的%util = 0.8/1 = 80%，該參數暗示了設備的繁忙程度。
資源利用與負載對應關系
圖中拐點說明：
（1）服務器某一資源使用逐漸達到飽和
（2）通常可以利用拐點來進行性能測試分析與定位
性能計數器（counters）
是描述服務器或操作系統性能的一些數據指標，如使用內存數、進程時間，在性能測試中發揮着“監控和分析”的作用，尤其是在分析系統可擴展性、進行新能瓶頸定位時有着非常關鍵的作用。
常見性能瓶頸
吞吐量到上限時系統負載未到閾值：一般是被測服務分配的系統資源過少導致的。測試過程中如果發現此類情況，可以從ulimit、系統開啟的線程數、分配的內存等維度定位問題原因
CPU的us和sy不高，但wa很高：如果被測服務是磁盤IO密集型型服務，wa高屬於正常現象。但如果不是此類服務，最可能導致wa高的原因有兩個，一是服務對磁盤讀寫的業務邏輯有問題，讀寫頻率過高，寫入數據量過大，如不合理的數據載入策略、log過多等，都有可能導致這種問題。二是服務器內存不足，服務在swap分區不停的換入換出。
同一請求的響應時間忽大忽小：在正常吞吐量下發生此問題，可能的原因有兩方面，一是服務對資源的加鎖邏輯有問題，導致處理某些請求過程中花了大量的時間等待資源解鎖；二是Linux本身分配給服務的資源有限，某些請求需要等待其他請求釋放資源后才能繼續執行。
內存持續上漲：在吞吐量固定的前提下，如果內存持續上漲，那么很有可能是被測服務存在明顯的內存泄漏，需要使用valgrind等內存檢查工具進行定位。
性能瓶頸定位之拐點分析法
“拐點分析”方法是一種利用性能計數器曲線圖上的拐點進行性能分析的方法。它的基本思想就是性能產生瓶頸的主要原因就是因為某個資源的使用達到了極限，此時表現為隨着壓力的增大，系統性能卻出現急劇下降，這樣就產生了“拐點”現象。當得到“拐點”附近的資源使用情況時，就能定位出系統的性能瓶頸。
軟件性能的其它術語
思考時間的計算公式
Think Time，從業務角度來看，這個時間指用戶進行操作時每個請求之間的時間間隔，而在做新能測試時，為了模擬這樣的時間間隔，引入了思考時間這個概念，來更加真實的模擬用戶的操作。
在吞吐量這個公式中F=VU * R / T說明吞吐量F是VU數量、每個用戶發出的請求數R和時間T的函數，而其中的R又可以用時間T和用戶思考時間TS來計算：R = T / TS
下面給出一個計算思考時間的一般步驟：
1、首先計算出系統的並發用戶數
C=nL / T F=R×C
2、統計出系統平均的吞吐量
F=VU * R / T R×C = VU * R / T
3、統計出平均每個用戶發出的請求數量
R=u*C*T/VU
4、根據公式計算出思考時間
TS=T/R
UNIX資源監控指標和描述
監控指標 描述
平均負載 系統正常狀態下，最后60秒同步進程的平均個數
沖突率 在以太網上監測到的每秒沖突數
進程/線程交換率 進程和線程之間每秒交換次數
CPU利用率 CPU占用率（%）
磁盤交換率 磁盤交換速率
接收包錯誤率 接收以太網數據包時每秒錯誤數
包輸入率 每秒輸入的以太網數據包數目
中斷速率 CPU每秒處理的中斷數
輸出包錯誤率 發送以太網數據包時每秒錯誤數
包輸入率 每秒輸出的以太網數據包數目
讀入內存頁速率 物理內存中每秒讀入內存頁的數目
寫出內存頁速率 每秒從物理內存中寫到頁文件中的內存頁數
目或者從物理內存中刪掉的內存頁數目
內存頁交換速率 每秒寫入內存頁和從物理內存中讀出頁的個數
進程入交換率 交換區輸入的進程數目
進程出交換率 交換區輸出的進程數目
系統CPU利用率 系統的CPU占用率（%）
用戶CPU利用率 用戶模式下的CPU占用率（%）
磁盤阻塞 磁盤每秒阻塞的字節數