性能的指標參數

名詞解釋

1. 線程數

能以線程式并發的方式，幫我們達成“短時間內向服務器發送大量請求”這一任務。

多線程式并發測試工具，顧名思義，會啟動復數個線程，讓每個線程獨立向服務器端發出請求。

2. TPS Transactions Per Second（每秒傳輸的事物處理個數）

即服務器每秒處理的事務數。TPS包括一條消息入和一條消息出，加上一次用戶數據庫訪問.

一個事務是指一個客戶機向服務器發送請求然后服務器做出反應的過程。客戶機在發送請求時開始計時，收到服務器響應后結束計時，以此來計算使用的時間和完成的事務個數。

TPS的高低也會像木桶效應的影響與多種因素相關，當一處存在短板時會導致整個接口乃至系統的出現TPS上不去的情況。

3. 響應時間

從用戶發送一個請求到用戶接收到服務器返回的響應數據這段時間就是響應時間

關鍵路徑：下圖為一次http請求經過的路徑，請求會經過網絡發送到web服務器進行處理，如果需要操作DB，再由網絡轉發到數據庫進行處理，然后返回值給web服務器，web服務器最后把結果數據通過網絡返回給客戶端

Response time = (N1+N2+N3+N4)+ (A1+A2+a3)，即：（網絡時間 + 應用程序處理時間）
事務平均響應時間。
單個事務平均下來完成的速度越快，那么單位時間內能完成的事務數就越多，TPS就就越高

4. 95分位響應時間

請求數的響應時間從小到大排序后，剔除末端的百分之五的響應時間后得到的最高的響應時間稱為95分位的響應時間，這樣可以將瞬間的毛刺（尖峰）去掉，同時95分位與平均響應時間之差越小，表示系統的響應越趨于穩定

5. 請求錯誤個數

顧名思義：當前請求中出現的錯誤個數，可能是由于斷言問題、服務器響應、資源丟失等問題造成的，常見的服務器響應碼有404/500/502等，當出現錯誤個數我們可以調取jmeter的log來查看相應的報錯日志。

常見的請求狀態碼

200：正確的請求返回正確的結果，如果不想細分正確的請求結果都可以直接返回200

301：請求成功，但是資源被永久轉移。比如說，我們下載的東西不在這個地址需要去到新的地址。

400：請求出現錯誤，比如請求頭不對等。

401：沒有提供認證信息。請求的時候沒有帶上 Token 等。

403：請求的資源不允許訪問。就是說沒有權限。

404：請求的內容不存在。

500：服務器錯誤。代碼有問題，需看下服務端代碼

502：網關錯誤，多為配置了Nginx網關，未啟動相應的服務

503：服務暫時不可用。服務器正好在更新代碼重啟。

6. 系統CPU使用率

使用率包含user（用戶）和sys（系統），CPU使用率指的是程序在運行期間實時占用的CPU百分比，這是對一個時間段內CPU使用狀況的統計。通過這個指標可以看出在某一個時間段內CPU被占用的情況。
在壓測過程中user+sys的應控制在80%以下，高于80%服務器將存在一定的負載壓力，服務器有瓶頸，導致壓測結果不準。
top命令查看服務器CPU使用率和負載

7. 系統CPU負載

cpu負載是衡量一臺服務器使用資源情況的提現，當負載越高時，服務器的壓力越大。
如：一座橋上，沒有車流量負載為0，為1時剛好滿足橋面的正常通行，但是車流已經很堵了，如果到2到3則說明，橋已經堵的基本動不了了，車輛都停在次等待通行，cpu負載也如此，但是理想情況是滿負載情況下的百分之70%。
如何計算服務器的負載？
grep ‘model name’ /proc/cpuinfo | wc -l
服務器的滿負載是32，所以負載低于22.4屬于正常，越高則可能影響到壓測數據的分析。

8. 流量

流量的消耗包好進入服務器的流量和服務器往外部發送的流量，
進服務器的流量： 接口請求進入的流量，另外一方面 是從db/redis讀取數據返回來的流量
出服務器的流量： 發起去讀redis/mysql的語句，另外一方面就是服務器返回給壓力機的返回結果流量
流量的高低可能會受服務器的帶寬影響，當數據流量很大時，服務器已達到了最大帶寬使用，會導致TPS無法繼續增長的問題

性能瓶頸淺析（TPS無法提高）

1、網絡帶寬
在壓力測試中，有時候要模擬大量的用戶請求，如果單位時間內傳遞的數據包過大，超過了帶寬的傳輸能力，那么就會造成網絡資源競爭，間接導致服務端接收到的請求數達不到服務端的處理能力上限。

2、連接池
可用的連接數太少，造成請求等待。連接池一般分為服務器連接池（比如Tomcat）和數據庫連接池（或者理解為最大允許連接數也行）。

3、垃圾回收機制
因為java的的堆棧內存是動態分配，具體的回收機制是基于算法，回收如果較頻繁，那么對TPS
也是有一定影響的，因為垃圾回收其本身就會占用一定的資源。

4、數據庫配置
高并發情況下，如果請求數據需要寫入數據庫，且需要寫入多個表的時候，如果數據庫的最大連接數不夠，或者寫入數據的SQL沒有索引沒有綁定變量，抑或沒有主從分離、讀寫分離等

5、硬件資源
包括CPU（配置、使用率等）、內存（占用率等）、磁盤（I/O、頁交換等）。

6、壓力機
比如jmeter，單機負載能力有限，如果需要模擬的用戶請求數超過其負載極限，也會間接影響TPS（這個時候就需要進行分布式壓測來解決其單機負載的問題，一般情況單臺夠用）。

7、業務邏輯
業務解耦度較低，較為復雜，整個事務處理線被拉長導致的問題。

8、系統架構
比如是否有緩存服務，緩存服務器配置，緩存命中率、緩存穿透以、緩存過期、是否含有死鎖等，都會影響到測試結果。

性能拐點圖

圖中有三條曲線，分別表示資源的利用情況

Utilization，包括硬件資源和軟件資源

吞吐量（Throughput，這里是指每秒事務數）

響應時間（Response Time）。

圖中坐標軸的橫軸從左到右表現了并發用戶數（Number of Concurrent Users）的不斷增長。

在這張圖中我們可以看到，最開始，隨著并發用戶數的增長，資源占用率和吞吐量會相應的增長，但是響應時間的變化不大；
不過當并發用戶數增長到一定程度后，資源占用達到飽和，吞吐量增長明顯放緩甚至停止增長，而響應時間卻進一步延長。
如果并發用戶數繼續增長，你會發現軟硬件資源占用繼續維持在飽和狀態，但是吞吐量開始下降，響應時間明顯的超出了用戶可接受的范圍，并且最終導致用戶放棄了這次請求甚至離開。

當系統的負載等于最佳并發用戶數時，系統的整體效率最高，沒有資源被浪費，用戶也不需要等待；當系統負載處于最佳并發用戶數和最大并發用戶數之間時，系統可以繼續工作，但是用戶的等待時間延長，滿意度開始降低，并且如果負載一直持續，將最終會導致有些用戶無法忍受而放棄；而當系統負載大于最大并發用戶數時，將注定會導致某些用戶無法忍受超長的響應時間而放棄。

根據此圖可以知道，當性能出現瓶頸時往往伴隨著響應時間的成倍增長和吞吐量的下降，在我們進行壓測的過程中可以適當增加并發的線程數，來根據接口的響應時間和吞吐量的值來判斷是否出現了性能瓶頸，當出現性能的瓶頸時我們可以根據前面所講到的方式去觀察服務器的資源使用情況，數據庫連接池等配置來對接口進行分析

總結

以上是生活随笔為你收集整理的【性能测试基础】性能专有名词解析及性能瓶颈分析技巧的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。