壓力測試

模擬用戶在同一時間對服務器發送大量請求，以此查看服務器性能指標，尤其關注大業務量情況下運行系統性能的變化（反應變慢、是否會內存泄漏導致系統逐漸崩潰、是否能恢復），測試系統的限制和故障恢復能力，找系統瓶頸

1、需加集合點，模擬用戶瞬間并發，對服務器沖擊力大

2、只執行一次，不需設置持續運行時間

3、每3秒進5個人，用戶達到30 50 80集合后分別壓測，然后利用二分法不斷取中間值，找出最大吞吐量

尖峰測試（Spike testing）Ultimate Thread Group（終極線程組）

在性能測試中屬于壓力測試的一個子集。指的是在某一瞬間或者多個頻次下用戶數和壓力陡然增加的場景。

場景1：

網站平穩運行時，突然有一波1000用戶同時訪問（第1浪潮），訪問了30s之后，第一浪潮在15s內逐漸退出系統同時；

第二波2000用戶在極短時間內又突然涌入網站（第2浪潮）。訪問30s之后，第二浪潮在15s內也逐漸退出了系統。

并發用戶數

實際就是在線用戶數,相對并發用戶數,在一個時間段內，與服務器進行了交互、對服務器產生了壓力的用戶的數量。這個時間段，可以是一天，也可以是一個小時

1、并發用戶數標準不能以注冊用戶數為標準，應以在線用戶數為標準或同時發請求用戶更準，或注冊用戶數20%

2、并發用戶數= 系統總用戶數20%—30%

3、并發越大，響應時間越長，也跟吞吐量和服務器處理能力有關

4、每隔5分鐘增加一定的并發數，直到達到瓶頸數，即線程數增加了以后tps處理量不在增加了，這個線程數可以算成合理的并發數。

負載測試

測試在一定負載情況下系統性能，逐步增加用戶數量或用戶請求來對系統進行加壓，直到系統響應超時或關鍵資源耗盡，得到不同負載下系統性能指標，不關注穩定性。（關注最大安全臨界負載量、吞吐量）

1、不加集合點，逐漸增加用戶到系統瓶頸。對服務器沖擊力小

2、需設置持續運行時間

3、逐漸增加用戶，持續運行，直至達到系統瓶頸

穩定性測試

網站承受的最大負載值下，持續長時間運行，以此查看服務器的穩定性

1、不加集合點，逐漸增加用戶到最大負載量（負載測試最大點）

2、達到最大負載需設置持續運行時間

3、逐漸增加用戶到最大負載量，然后再持續運行一段時間（穩定性測試時長），然后逐漸退出

故障轉移測試

恢復測試，是要把服務器壓崩潰，測試另一臺服務器是否可正常頂上

系統用戶數（注冊用戶數）

在線用戶數（相對并發用戶數）

絕對并發用戶

主要是針對某一個操作進行測試，即多個用戶同一時刻發起相同請求,驗證是否存在并發邏輯上的處理問題，如線程不安全、 死鎖等問題；也可提供一些性能上的參考

日常壓力(日常數據分析)

測試場景，就是要用500個用戶在4小時內完成“每人發一個帖子、瀏覽十個帖子”的工作量。

高峰期壓力(日常數據分析)

是指系統正常的、預期內壓力的一個高峰

峰值壓力，不在正常預期內的壓力

?

性能指標:

1、吞吐量

服務端返給客戶端的數據量，是指對網絡單位時間內成功地傳送數據的數量，是單位時間服務器處理事務的總數

Tps 是服務器每秒處理的事務字節數

隨用戶數逐漸增多，吞吐量應該是遞增，如果吞吐量下降，服務器處理事務能力下降，響應時間變長，達到系統瓶頸

2、請求響應時間

從客戶端發起的一個請求開始到客戶端接收到服務器返回結束所耗費的時間=網絡響應時間+應用層響應時間

3、事務響應時間

用戶的一個操作的響應時間，是由一系列請求的響應時間組成

4、CPU

中心處理單元，由控制單元和運算單元組成，對數據進行處理，并發出控制命令，協調周邊設備運行，對數據判斷極邏輯處理，不能存儲數據，從內存中讀取數據進行邏輯計算，如果內存中沒數據，才會從硬盤中讀數據到內存，再進行邏輯計算，不能高于75%

5、錯誤率

6、內存

liunx內存工作原理，內存8g ?優先分出7g ?一部分分給應用，一部分分給緩存內存，放應用內存不足時，會把緩存內存優先分給應用

?

性能問題及其BUG

1、大數據量下，產生的性能問題

2、大訪問用戶量下，產生的性能問題

3、預估未來數據量，產生的性能問題

4、大結果集下，產生的性能問題

5、大復雜邏輯下，產生的性能問題

6、數據庫產生的性能問題（未分庫、未分表、未主從分離、數據庫結構、SQL慢查詢、實時查詢、索引優化(建立主鍵或唯一索引、未使用聯合索引)

7、性能缺陷：（并發錯誤、死鎖、內存泄露）

8、cpu處于70%-100%之間波動

?

需求產生

分析用戶是如何使用系統，用戶對哪些業務性能比較敏感，系統的一些關鍵業務實現邏輯，從設計實現的角度來看哪些業務的性能可能存在隱患

通過友盟、阿里云、埋點、數據庫、產品、運維等收集信息，分析系統、分析業務、分析用戶行為等

注冊用戶數、在線用戶數、日常壓力、峰值壓力、高峰期壓力

1、產品、研發有明確需求

2、無明確需求，初次上線系統，需用同行系統數據，進行用戶行為分析和商業數據結構的估算，利用性能估算推算，幫助決策，形成性能需求

3、無明確需求，已上線系統，通過運維獲取tps和時間比例分布圖、用戶數和時間的分布圖、數據庫ER關系圖、容量數據，得出性能需求

4、無明確需求，系統關鍵模塊、性能隱患模塊、用戶敏感性能模塊，確定性能需求

5、無明確需求，根據用戶的使用行為，使用習慣，確定性能需求

6、無明確需求，參考系統歷史3個月/6個月/1年數據、用戶歷史行為，預測未來數據，確定性能需求

7、無明確需求，進行峰值測試或穩定性測試，測出系統的性能瓶頸，評估是否達到預期。

?

需求分析

1、系統類型、特點、架構和設計

2、深入理解被測系統，確定系統的關鍵業務模塊，從設計實現邏輯確認性能隱患的模塊、用戶敏感的性能模塊、用戶使用行為，整理測試思路、制定測試方案、產生測試場景

3、 如果沒有明確的性能需求，則根據歷史數據或類似系統，由項目組評估出性能指標；

4、進行峰值測試或穩定性測試，測出系統的性能瓶頸，評估是否達到預期。

?

測試準備

1、控制機、壓測機、壓測環境

2、測試數據、業務數據 、測試性能模擬的壓力數據、

3、數據來自生產環境、最大可能模擬生產數據

4、根據經驗預估的數據、根據歷史數據預估的未來數據

?

環境準備

1、操作系統、服務器配置分析，需了解系統的架構和設計

2、了解cpu信息

3、用戶量（PV、PU、業務量）

4、服務器重啟重置環境，干凈的系統環境，無運行程序和腳本

5、負載機環境

6、測試環境要盡量的模擬生產環境

?

壓測場景模擬（模擬所有可能發生的極端的訪問情況）

基準測試、日常壓力測試、峰值壓力測試、絕對并發測試、穩定性測試

壓測策略?

? ? ? ?1、基準測試，一個用戶循環壓5分鐘 獲取系統在沒有壓力的情況下響應時間，為下一步測試性能拐點做比對

? ? ? ?2、負載測試，單個交易多個用戶并發10，測試驗證系統并發情況下是否有并發性的錯誤 應用鎖 數據庫鎖

? ? ? ?3、容量測試，多個交易按一定比例去配比 再按一定的體度 一定的梯度10 20 30逐步去施壓，到獲得這個系統的性能拐點，資源站用達到很高?

? ? ? ?4、穩定性測試 ?一定壓力下長時間運行穩定的能力，是不是存在內存泄露、數據庫查詢慢

?

1、疲勞壓測（穩定性壓測），持續壓測5小時，測試性能指標

2、并發壓測，單接口瞬間啟動100線程并發，測試性能指標

3、日常壓測，根據每日數據分析，如：500個用戶在4小時內完成“每人發一個帖子、瀏覽十個帖子”的工作量，測試性能指標

4、業務壓測，多接口業務流程壓測，測試性能指標

5、峰值壓測（極限壓測），測試最大并發量，測試性能指標

6、階梯壓測,逐漸改變線程數進行壓測，性能指標

7、大數據壓測，數據量過大進行壓測，性能指標

8、負載測試，分別壓測50、100、150時，性能指標

9、數據庫讀寫壓測

案例：

1、比如購物：30個用戶模擬登陸，10個用戶瀏覽商品，30用戶商品下單，20個查訂單，10個做退出登錄

2、25線程，5s后啟動5個線程，再每隔5s啟動5個線程運行10s，達到10線程運行20s，每隔3s停5個線程

3、2000用戶在線登錄狀態，這2000用戶中要達到100用戶并發去訪問首頁，總的線程設置2000并發，其中95%的用戶是登錄狀態，5%用戶訪問首頁狀態，采用固定定時器和吞吐量控制器

4、1w用戶在線，模擬1w用戶登錄后操作一些系統中各個頁面

5、【日常壓力】活躍用戶500人，每人每天發1帖子、瀏覽10帖子，平均每天產生500新帖子、瀏覽帖子5000次。用戶使用論壇時間段集中在中午11點到1點和晚上18點到20點。每天的這些業務，實際分布在4個小時中完成的。那我們測試場景，就是要用500個用戶在4小時內完成“每人發一個帖子、瀏覽十個帖子”的工作量，注意“平均每天……”、“分布在4個小時……”。這個場景測的是平均壓力，也就是一個系統最平常一天的使用壓力

6、【高峰期壓力】比如“平均每天總的發帖量……”，那么就要查過去最高一 日的業務量。“分布在4個小時”也需要進行相應的修改，或查下歷史分布圖是否有更集中的分布，或用更簡單通用80-20原則，80%工作在 20%時間內完成。根據這些數據可以再做適當的調整。

7、按照時間，使用遞增的線程并發數來測試，比如每5分鐘加5或10個線程，一直測試1小時，查看系統性能是如何波動的，這樣就能基本找到產品的最大極限值即峰值、性能拐點

8、比如：一個系統日均1萬人訪問，一天平均3次/人，一般集中在每天晚上8點-10點，則我們可以算出每天1萬人*3次/人=3萬次請求，1天3萬次請求集中在8點到10點3個小時之內，3萬次請求集中在3小時之內，則平均每小時訪問1萬次請求，則每秒就是10000次/3600s大約為3次/s，即根據以往運營日志得出每秒鐘3次請求，按照我們的并發峰值4倍的策略，則我們的性能指標可以定在4*3=12次/s，即我們的每秒處理事務數可以按照12次/s的基礎來參考。

?

結果分析（硬件配置-操作系統-數據庫-中間件-后端應用-前端應用）

1、服務器性能（哪些資源cpu占用過大、內存占用、硬盤占用、I/O讀寫）

2、Tps每秒處理事務個數 每個事務處理的平均時長

3、TPS（每秒處理請求數）、響應時間（服務器響應時間+網絡時間）、錯誤率、QPS（每秒從服務器接收的數據量）

4、數據庫（或中間件）非常慢了

5、中間件無響應

JVM堆內存用滿，不停的進行GC，導致響應超慢（但是還沒有OOM，否則就報錯了）處理HTTP請求的線程，都被占用或者鎖住

6、系統響應慢、超時、失敗

7、服務器掛掉

8、網絡（防火墻是否開啟、端口的訪問、寬帶是否有被限制、路由尋址、網絡的時延）

9、代碼性能

10、定位分析問題：

? ? ? ? 10-1、網絡忙不忙 網絡延遲大不大 網卡流量 是不是達到網卡瓶頸

? ? ? ? 10-2、操作系統 應用服務器和數據庫服務器資源cpu、內存占用、io讀寫

? ? ? ? 10-3、數據庫鎖 運行等待等?

? ? ? ? 10-4、應用系統日志死鎖 wait?

? ? ? ? 10-5、前端連接數是否正常?

? ? ? ? 10-6、與運維確認是否開了流量控制

? ? ? ? 10-7、再嘗試重啟應用服務器和數據庫服務器

?

性能調優

1、擴充服務器（網路、cpu、內存、硬盤、顯卡、I/o）

2、代碼調優

3、中間件

4、分庫、分表、主從分離、數據庫結構優化、SQL優化、索引優化(建立主鍵或唯一索引、使用聯合索引)

? ? ?4.1、SQL優化

? ? ? ? ? ? ?大表 左關聯 小表，很慢；小表 左關聯 大表，很快

? ? ? ? ? ? ? 嵌套的子查詢是很慢

5、多個服務器負載均衡、使用緩存服務器

6、設置虛擬內存

7、運維設置限流

8、添加緩存、圖片資源壓縮

?

測試報告

性能測試比對 1 每次版本性能測試比對 2 機器橫向增加 ，增加前后性能測試的比對 3 性能優化 優化前后的性能測試比對

?

如何確定系統性能測試tps需求標準？

已上線項目

查看過去1周（或1月）內，接口調用量最高的1天，然后再找當天接口調用量最高的時間點（分鐘級別），比如在12:10調用量為10000，換算為每秒調用量10000/60=166，因此可以確定這個接口tps只要達到166即可滿足。

未上線項目

二八定律（無歷史數據參考） （日活用戶*總請求數*80%）/（24h-（0-6h）*3600秒*20%）*系數（2-5之間）=tps

1、先預估系統每日總請求數，如果沒有歷史數據參考，一般是通過用戶量或者其他關聯系統來評估。

比如某網站新增每日簽到送積分功能，網站注冊用戶1000w，日活躍用戶100w左右，最極端情況下，這100w人都會來簽到（實際不會這么多人來簽到，評估指標要盡量往高評，以免出現極端情況），那么每天大概有100w次簽到請求，80%的請求數就是100w*0.8=80w。

2、再確定系統20%時間，大多數系統是24小時對外提供服務的（比如政府類項目，在一天某個時間段提供服務）。

一般系統0點-6點之間訪問量很少，從一天總訪問量來看，可忽略不計。那20%的時間=（24-6h）*3600s*20%=12960秒。

3、最終計算出來的結果為80w請求/12960秒=61左右。也就是說接口TPS滿足61即可。

4、最后再乘以一個冗余系數2-5之間，提高預期指標，防止人為評估造成預期指標偏低情況。

可以通過對項目接口的峰值監控，來對比之前評估的算法結果，調整冗余系數，最終隨著不斷的數據積累，將會形成一套本項目的性能模型。

?

?

總結

以上是生活随笔為你收集整理的【性能测试】性能需求挖掘、性能方案制定及压测场景设计之疑惑与思考（一）的全部內容，希望文章能夠幫你解決所遇到的問題。

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