一、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的作用
例一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不退出（永遠循環），通過調度器設置運行時間。