一、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不退出（永遠迴圈），通過排程器設定執行時間。