性能測試-并發測試心得

一些關鍵名詞

吞吐量

指的是在一定時間內系統處理請求或傳輸數據的能力，具體到性能測試中的話，就是指單位時間內系統處理并完成的請求數量或者是系統傳輸的數據量。

例如，吞吐量可以表示為系統每秒處理HTTP請求次數，或者是系統每秒鐘完成的事務數量（TPS）。

這個指標很大程度體現了系統的處理效率和負載承載能力。

對于這個指標，影響其的因素與CPU、磁盤的I/O緊密相關。

例如，一個Web應用在每次請求時都會去查詢數據庫，在并發數增加后，數據庫就會占用大量CPU和磁盤的I/O資源，就會導致其他的軟件被迫等待數據庫執行完后才能使用CPU，如果是這種情況，那么這個Web應用的接口設計就存在一定問題，吞吐量就不會太高

響應時間（Response Time，RT）

指的是從客戶端發起一個請求到服務器處理完成并返回響應結果所需要的時間間隔，簡單來說，就是客戶端從發起請求到收到響應的過程。這個時間會包括下述階段：

網絡傳輸時間：請求在網絡中傳播到服務器所需的時間
服務器處理時間：服務器接收到請求后，對其進行解析、執行業務邏輯以及數據處理所需的時間
數據庫查詢時間：如果涉及到數據庫操作，那么還包括數據庫查詢和返回結果所需的時間
生成響應時間：服務器構建并準備響應數據所需的時間
網絡返回時間：服務器將響應數據傳回客戶端所需的時間

在進行性能測試的時候，對于這個指標通常會關注最小響應時間、最大響應時間和平均響應時間，以及特定百分比（如90%、95%或99%）的響應時間

最小響應時間：這個指標表示在測試期間所有請求中響應最快的情況，用于了解系統在理想狀態下處理請求的能力。但單一的最小值并不能代表整體性能，因為實際運行環境中的大多數請求可能并不會達到這個速度
最大響應時間：最大響應時間反映出系統處理請求最慢的情況。如果最大響應時間過高，說明系統存在明顯的性能瓶頸或異常情況，這直接影響用戶體驗，需要重點排查和優化
平均響應時間：平均響應時間是所有請求響應時間的算術平均值，它提供了一個總體上系統的平均處理速度。然而，平均值容易受到異常值的影響，如果系統中有極快或極慢的響應時間，平均值可能無法準確反映大部分請求的真實響應情況
特定百分比的響應時間（如90%, 95%, 99%）：這些統計值代表了在所有響應時間中，有相應百分比的請求響應時間小于等于該值。例如，90% 表示有90%的請求響應時間不超過該數值。這些統計數據對于理解和改善用戶體驗非常關鍵，因為它們揭示了大部分用戶（或請求）的實際響應時間情況，尤其是95%和99%常被用來衡量系統的尾部延遲和性能瓶頸

TPS

通常指的是一秒鐘內系統成功處理事務的數量，這里的事務可以是一次登錄、一次交易、一次網頁加載等。

通過TPS可以了解到系統在不同負載條件下的處理能力上限，可以通過這個指標的突然改變來判斷“拐點”（詳見下文）

PV和UV

PV（Page VIew）：指的是每一次頁面查看或頁面訪問。每當用戶訪問網站的一個頁面時，無論該用戶是首次訪問還是刷新同一個頁面，都會被計為一個PV。PV反映的是網站內容被訪問的總次數，是衡量網站流量規模和受歡迎程度的一個重要指標。如果一個網站一天內被訪問了1000個頁面，那么這一天的PV就是1000

UV（Unique Visitor）：指的是獨立訪客數，即在一定統計周期內訪問網站的不同用戶數。通過識別瀏覽器的Cookie或IP地址等信息來區分不同的訪問者。即使同一位用戶在一天內多次訪問網站，也只會計入一個UV。UV強調的是訪問網站的人數而非訪問次數，它能更準確地反映網站的受眾群體大小。

PV著重于網站內容被訪問了多少次，而UV則是關注有多少不同的個體訪問了網站。在評估網站流量和用戶黏性時，PV和UV都是非常重要的統計指標。

為什么需要性能測試？

簡單而言：

追求更大的并發（擔心用戶太多，搞垮系統）
追求更短的響應時間（覺得系統太慢）
追求更低的成本（降低服務器配置）

具體而言：

評估系統容量和性能極限。例如，電商平臺在大型促銷活動期間（如雙十一）可能面臨數十倍于平時的用戶訪問量。通過性能測試，可以模擬這種高并發場景，預估系統在短時間內處理大量請求的能力。假設測試結果顯示系統在10萬并發用戶下仍能保持穩定的響應時間和較高的TPS，那么平臺就能有信心應對實際促銷期間的大流量沖擊。
發現和解決系統瓶頸。例如，一款多人在線游戲進行性能測試時，隨著玩家人數的增加，數據庫查詢、網絡通信、服務器CPU和內存使用率可能會上升。一旦到達某個閾值，響應時間可能急劇增加，這表明系統存在瓶頸。通過性能測試定位問題，比如發現數據庫查詢優化不足，進而調整索引、緩存策略或升級硬件設施來解決問題。
指導系統優化和擴展。例如，個企業級內部應用在新功能上線前進行性能測試，發現隨著并發用戶數增加，系統的吞吐量并未按預期線性增長。經過分析，發現是因為某種業務邏輯造成了大量線程阻塞，通過優化代碼結構和采用異步處理方式，使得系統在同等資源條件下處理更多請求，提高了系統的可擴展性。
成本效益分析。企業在選擇云服務提供商時，可以通過性能測試比較不同云服務方案的成本效益。例如，通過測試確定在何種資源配置下既能滿足業務需求又能最大程度節省成本，避免過度配置資源導致浪費，或資源不足導致用戶體驗下降。

性能測試需要得到怎樣的結論？

性能指標

接口在不同并發用戶數的響應時間。例如，在并發用戶數從100增加到1000的過程中，接口的響應時間可能從最初的100ms增加到500ms，表明隨著并發用戶的增多，系統的響應速度在降低。
TPS。例如，在并發用戶數為500時，系統的TPS能達到1000，但是當并發用戶數為1000時，系統的TPS僅提升到了1200，說明在這個區間中，系統的可擴展性有限，接近飽和點。
并發用戶數與響應時間、吞吐量的關系曲線。通過圖形，可以更加的直觀的看出隨著并發數增加到什么程度的時候，系統的TPS開始下降。

系統瓶頸

CPU、內存、磁盤I/O、帶寬等

例如，對于兩個Web應用，他們都用于處理用戶上傳的圖像并進行實時處理（如縮放、裁剪等）和存儲到數據庫。

A應用在高并發的情況下，能始終保持50%以下的內存占用，CPU在高峰期也能維持在60%以下

B應用在高并發的情況下，會經常觸發垃圾回收機制，會導致響應時間增加，CPU峰值常在95%以上，就會導致大量數據庫的I/O操作需要等待，進一步增加響應時間

那么B應用暴露的問題可能就是：

創建了需要不必要的對象，導致內存占用高，頻繁觸發垃圾回收機制，也可以使用更加高效的垃圾回收機制
可能有密集型的CPU操作，應該進行減少密集型操作，使用多線程、異步等方式來分散CPU負載
數據庫有大量I/O操作，可以考慮優化數據庫查詢語句、引入數據庫緩存機制、采用讀寫分離或分布式數據庫方案等手段降低磁盤I/O帶來的性能瓶頸

穩定性和可靠性

在高并發的場景下，系統是否會出現錯誤，例如死鎖、超時
以及處理高并發后是否會清理一些環境數據？例如，在高并發場景下，系統處理完大量請求后，應確保沒有遺留的打開文件、數據庫連接未關閉，以及內存泄露等問題，這對于系統的長期穩定運行至關重要

影響性能測試的因素有哪些？

并發訪問方式

一次性全部并發
階梯式增長并發
持續穩定并發

系統資源

服務器的硬件配置：CPU、內存、磁盤等物理資源，可能會在高并發的時候，進行I/O資源的搶奪，從而影響并發結果
針對于查詢類或修改類的接口，數據庫也會影響并發測試，例如數據量大小、索引效率、鎖機制、是否緩存
線程池大小、連接池的管理，都會影響并發結果

當然，如果在不同的并發測試中上述內容沒有被修改，那么上述內容也不是當次并發測試的影響因素

如何確定接口或者系統可以從哪些方面進行優化？

Jmeter如何快速確定拐點？

拐點

這個概念最開始是從性能測試的圖形化結果中引申出來的，可以很顯然的看到某個指標從一種狀態到另一種狀態的關鍵時刻

具體來說，在進行壓力測試的時候，隨著并發的用戶數的增加，系統的吞吐量（或TPS），一開始可能會隨著負載的增長而增長，但當達到某個特定的負載水平時，系統的性能就不會再按比例提升，甚至開始下降。

此時，系統的響應時間會明顯增加，錯誤率可能也會隨之增高，這個曲線的由增變緩或由降變增的轉折點就被稱為“拐點”

實例

接口文檔

對單個接口進行壓測，測試出一些關鍵數據

接口：https://keewood-v2-service.t.cn-shenzhen.aliyun.kkgroup.work/v4/console/dictionaries/{id}

文檔：https://teamshare.t.cn-shenzhen.aliyun.kkgroup.work/application/DT001/automated_testing/template/view/auto_test_api_manage?projectid=613331460681805825&cid=620940619036807169