一、90%響應時間（參考蟲師博客）

90%Line

一組數由小到大進行排列，找到他的第90%個數（假如是12），那么這個數組中有90%的數將小于等于12。

用在性能測試的響應時間，也就是90%請求響應時間不會超過12秒。

例如：

某一次測試結果，每個sample的響應時間分別是：1、3、4、9、2、8、5、7、6、10，將其按由小到大將其排列為：

1、2、3、4、5、6、7、8、9、10

那么它的第90%百分位，也就是第9個數剛好是9，那么他的90%Line就是9。即90%響應時間是9ms，理解為：90%的用戶請求時間不沖9ms。

另一測試結果，20個sample，響應時間分別為：

2、2.1、2.5、3、3.4、3.4、4、4、4、4、5、5、5、5.9、5.91、6.8、8、12、24、24.1按由小到大將其排列。

求它的第90%百分位，第18個數是12么，他的90%Line就是12。

二、事務

1、事務的組織

計算機術語中，事務應該具有4個屬性：原子性、一致性、隔離性、持久性。這四個屬性通常稱為ACID特性。

在性能測試腳本設計中，事務的設置至少應該遵守原子性，即不可分割性。

如購物事務一般包括登錄、查找商品、查看商品詳情、加入購物車、結算幾個步驟，每個步驟都缺一不可；

又比如轉賬業務（A賬戶向B賬戶轉出50元），包括A賬戶-50元、B賬戶+50元兩個步驟，每個步驟缺一不可。

再比如百度搜索，包括兩步：打開百度首頁，輸入關鍵字搜索，兩個步驟組成一個搜索事務。

常用的場景

1、事務=單個請求

2、事務=思考時間+單個請求

3、事務=多個相關聯的請求

如果事務中增加思考時間，運行結果統計的事務響應時間是包括思考時間的，所有場景的設計，腳本的設置，對測試結果是有影響的，具體需要根據需求進行設計。

2、項目舉例

項目一

需求：測試一個系統的TPS

分析：該系統包含多個功能點，選擇主要的功能點進行壓測

設計：每個功能點設計為一個事務，每個事務包含N個請求，通過腳本描述。

項目二

需求：有一個接口，用于跟蹤用戶行為，一旦用戶登錄就上傳用戶的登錄時間。要求：測試一下性能看能撐多少用戶同時在線。

分析：單個接口（請求）無需事務概念

項目三

需求：測試一下某個電商系統能同時支持多少用戶下單并購買成功

分析：業務是下單并購買，包含多個請求，需要組織成事務

三、TPS

1、TPS、TPM、QPS、PV

pv 是指頁面被瀏覽的次數，比如你打開一網頁，那么這個網站的pv就算加了一次；
tps是每秒內的事務數，比如執行了dml操作，那么相應的tps會增加；

tpm是每分鐘的事務數。
qps是指每秒內查詢次數，比如執行了select操作，相應的qps會增加。

不同的應用系統tps,qps是沒有可對比性的。
例如：
應用A，每個select查詢需要1ms, 一個connection的話，一直不停的執行，1S內 可執行1000次，也就是1000qps
應用B，每個select查詢需要100ms, 一個connection的話，一直不停的執行，1S內 可執行10次，也就是10qps

上面不同系統的兩個qps是無法對比的，不能說哪個好哪個壞。

2、TPS的作用

例一
某單個接口，tps=10，希望這個接口每天能處理100萬個請求，問能否滿足？
1）每分鐘處理60*10=600個請求
2）每小時處理600*60=36000個請求
3）每天處理24*36000=864000個請求
不能滿足需求

例二
希望某個接口每天能處理200萬個請求，問TPS至少應該達到多少？
200*0000/24*3600=28

例三
釘釘打開系統，9:00上班，8:30-9:00期間打開，一般集中在30分鐘。
公司500人，平均每個員工打卡1.6次（有人怕沒打上會再打），算一下TPS多少能支撐目前的應用不掛？
tps=500*1.6/30*60=0.44
如果是10分鐘以內打完卡
tps=500*1.6/10*60=1.3
如果是集中在最后一分鐘
tps=500*1.6/1*60=13

假設現在一臺服務器的tps是7，那么至少需要2臺服務器
這兩臺服務器平時都很閑，只有上下班時才忙，該如何設計？（類似的還有新浪微博，流量激增時可能需要1000臺，平時500臺即可）
使用動態擴容，熱點警告

3、常用的應用場景

tps常常是有限制的，如cpu<80%,內存<60%時的tps

cpu使用率和內存占用率往往是默認的或取經驗值

CPU	內存	用戶數	tps	策略
已知	已知	已知	？	按指定用戶數，設置釋放策略，持續較長時間（30分鐘），監控CPU、內存，取平均tps
默認	默認	？	已知	持續加壓（增加用戶數）看何時能達到目標tps，同時監控系統資源
經驗值	經驗值	？	？	什么都不知道的情況下，cpu、內存取經驗值，持續加壓，看系統的最大tps
？	？	不用太多	？	穩定性測試，用戶不用太大，長時間運行（永遠），監控cpu、內存、tps

容量測試：一般可設置運行1小時

壓力測試：一般可設置10分鐘

穩定測試：7*24小時、5*24小時

很不明確的需求：一般測試最大TPS

4、常見問題

如果某一次測出的TPS非常小，怎么辦？

可能的原因

1）服務器處理能力本如此

2）負載機的用戶數沒發出去，如給10個用戶，只發了3個用戶。如果是這種情況，可以用siege試一下

3）如果這時的CPU和內存占用也很小，可能是網卡滿了

5、性能調優的本質

拿時間換空間
拿空間換時間

時間：響應時間

空間：緩存

三、并發

1、并發量怎么理解

測試計劃包三個線程組，分別如下：

線程組1：線程數200，Ramp-Up Perios200秒——每秒并發1

線程組2：線程數200，Ramp-Up Perios100秒——每秒并發2

線程組3：線程數200，Ramp-Up Perios10秒——每秒并發200

測試計劃運行時是同時運行的，無delay。

并發分析

前10秒：200+1+2=203

10秒到100秒：1+2=3

最后100秒：1

第0秒：user1被創建，執行所有的samples用了10s,并發1

第1秒：user2被創建，執行所有的samples用了10s,并發2（user1+user2）

...

0秒——10秒，并發量遞增1.2.3....10

第10秒：user1執行完退出，user11被創建，并發量10

第11秒：user2執行完退出，user12被創建，并發量10

...

10秒——200秒，并發量穩定保持在10

所以，一個用戶的存活時間可以影響并發。jmeter報告中一般會有一個平均并發數

2、實際案例

某場景要求：100個用戶，希望每秒并發數是100。該怎么做？

（1）100用戶，20s釋放，逐漸加壓

（2）用戶創建后不讓其退出，循環次數設置為永遠

（3）這樣第20秒時，肯定能達到100并發，更加精確。

所以如果要精確控制并發量的話，建議thread不退出（永遠循環），通過調度器設置運行時間。

總結

以上是生活随笔為你收集整理的Jmeter中一些概念的理解——90%响应时间、事务、并发的全部內容，希望文章能夠幫你解決所遇到的問題。

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