根據學習全棧測試博主的課程做的筆記
一、說明
若未特別說明，涉及術語都是jmeter來說，線程數，就是jmeter線程組中的線程數
二、軟件性能是什么
1、用戶關注：響應時間
2、業務/產品關注：響應時間、支持多少并發數、對業務的處理能力
3、運維關注：響應時間（是否有超時的請求）、資源利用率、穩定性等
4、dba關注：響應時間（慢sql或者死鎖），關注數據庫的資源利用情況（表空間的資源使用情況）
5、開發關注:響應時間(代碼邏輯的處理快慢，特別是鎖，鎖的力度不合理導致后來的請求響應時間長）
6、架構師關注：架構是否涉及合理（是否具備擴展能力）
7、測試關注（關注6類用戶關注的）：響應時間、處理能力（TPS）、穩定性、什么時候進行擴展等
三、幾個性能測試相關得概念
1、 負載測試：不同客戶端線程數下服務器處理的能力
客戶端線程數下即就是jmeter下的線程數
模擬客戶端向服務器發送壓力
2、容量測試:強調的是容量測試、業務（混合容量tps），當前支持的最大容量、對未來容量的規劃
數據庫容量即就是數據庫的數據量
3、遞增測試：強調的是遞增，連續遞增加壓，看服務器的處理能力
4、 強度測試：用大量的客戶端，并發線程看服務端表現情況
5、性能測試：在某個特點的硬件、軟件、網絡設計場景模擬并發請求，通過監控分析進行調優，達到性能測試目標
6、總結
前面的四種強調的是不同的性能測試方式，性能測試場景的設計。可以將四種測試設計在里面。負載測試（場景就是階梯加壓，每個階梯對應的就是客戶端的線程數，對應的負載，再測一個最大值。
遞增測試：連續階梯加壓。
強調測試：連續階梯加壓，測試最大值。
四、性能測試中的關鍵術語
1、 并發、線程、tps
1.1公司要求500并發、500并發表示什么？
1.2并發分類、以及線程、tps的關系
1.2.1絕對并發–狹義：表示服務端某一個時刻物理的請求數。處理的請求數和什么有關系？
如某一個服務器是16c，64g,某一個時刻處理多少請求和邏輯cpu有關系，實際測試時服務端做并發。
1.2.2相對并發-廣義/tps
某一個時間段內處理的請求數，相對并發才是真正服務器的處理能力。不是站在服務器邏輯cpu的角度。
平時的并發就是相對并發，就是tps。
tps就是每秒鐘處理多少個請求，1s是時間段。
為什么并發是tps？
解釋：并發=tps，需要站在客戶端和服務端的視角下。
上面兩個并發僅站在服務端的角度，tps是要站在客戶端和服務端的視角下。把并發分為客戶端并發和服務端并發。
很多都是認為客戶端jmeter處的線程數就是并發數.,其實沒啥問題，但是需要認定為客戶端并發，而并不是服務端并發。還把并發分為客戶端并發和服務端并發。
1.2.3客戶端并發
此處的jmeter中的線程數是模擬大量請求對服務端產生壓力,此時的數值在性能測試中是沒有參考意義的。
此處并不能說明值設計的越大，性能就越好。而是需要看服務器的處理情況(服務器的tps、成功率、響應時間）
一般說的并發說的是服務端的并發。
并發不等于線程數,為什么?
舉例：若每秒的線程數為10，每個線程數1s內可以完成10個事務，循環發10次請求。此處完成的請求是100個，看性能需要看服務端而不是客戶端，服務端相當于是10個線程，完成了10個事務，循環發了10個事務的請求，服務端都進行了處理。即并發–100，則tps是100。
線程是否是用戶 10個線程不等于10個用戶(虛擬用戶）
領導要求500并發，并不是說jmeter客戶線程數設置就是500.jmeter的線程數是可以隨意設置的最好的就是連續加壓，可以看到每個階梯的tps使用情況再看監控。
每個線程1s，階梯加壓到50個線程時tps就是500。
前提：tps服務器處理請求隨著jmeter線程數增加而線性增加。
壓測不僅要壓目標tps，還需要壓測出最大的tps.
50個線程已經達到500目標tps。假設在200個線程時，線程增加時，最大的目標tps則為2000，繼續加壓時，tps則下降，這時已經超過服務器的最大處理能力，請求都在排隊，響應時間增長。
所以如果一個系統的響應比較快，1個線程1s時間內可以完成10個事務，需要設置的線程數是小于客戶端jmeter的線程數。
并發：客戶端的并發只是為了模擬用戶給服務端加壓力，他是沒有參考意義的，是需要服務端的并發,服務端的并發是tps
線程是否=用戶？(虛擬用戶）
線程不等于用戶（為什么？
因為線程做了用戶的動作，線程的每一次迭代才稱為用戶）即jmeter處的循環次數，發一次請求服務端給一次響應，這個是迭代。
注冊場景：
1s內，1個線程可以發10次請求，注冊時用戶名需要不一樣，此時假設已經參數化并且參數是足夠多，1個線程1s可以發10次請求就相當于10個用戶進行注冊，10個線程就是發100個請求，即就是100個用戶進行注冊，100個用戶用戶名不同。并發用戶數此時是100，tps100，壓力線程數是10.
可以這么理解：
線程只是執行用戶的操作，線程的每一次迭代是模擬了用戶的操作。
事務（關注流程,整個流程就為請求，若不關注流程，一個請求就是一個事務就是）
1.2.4服務端并發（站在業務層面，站在服務器的處理能力進行談并發）
客戶端并發只是為了向服務端發送壓力，并沒有什么參考意義。
服務端并發的：前提是需要保證事務的成功率，具體是多少，看行業要求，涉及到金錢事務的成功率是100%，涉及到其他一般是項目組定(如99.9%）
1.2.5線程和tps的瞬時計算
線程和tps的瞬時計算，并不是整個的計算
此處表面3個線程，1s可以完成5次請求，3個線程即就是3*5=15，
tps=15=總請求數/并發時間=15/1s=35=3（1000ms/200ms）
總請求數/并發時間=線程數*(1000/rt每個請求的響應時間)
rt是瞬時值
2、QPS和TPS的區別
QPS（Query Per Second）:每秒鐘的查詢
TPS（Transaction per Second)）：每秒鐘的處理事務數
3、響應時間rt：判斷業務快慢的指標
正常的性能壓測響應時間都是從低到高
剛開始壓力小時，服務器都能進行處理，響應也比較快。隨著壓力越來越大，處理不過來，請求排隊。
3.1rt增加、表示開始出現性能瓶頸
3.2補充瓶頸分析
此處簡單介紹，后面詳細解釋
3.2.1簡單架構
對于簡單架構，一般是通過服務器的資源情況進行判斷是否出現瓶頸。
3.2.2復雜架構（微服務）
對于復雜架構
就需要進行去分解響應時間看什么地方耗時多。
對時間的分解的方式：日志打點計時器,通過日志去查看請求的時間，
對于微服務最后是：鏈路監控工具（skywalking)
4、 線程、tps、rt三者的關系
4.1線程、tps、rt三者關系圖
jmeter線程數增加，發送的請求增加，剛開始都能處理，隨著增加線程逐漸增加，服務器的資源利用率就會增加（cpu、mem），此圖，tps隨著線程數的增加是線性增加，到了一定階段后，服務器出現了瓶頸后，響應時間開始增加，tps達到最大值后，tps增幅趨于平穩或者下降
4.2連續階梯加壓場景設計圖（這個是用插件實現的）
圖上斜的就是啟動線程，啟動多少線程
啟動后又可以平穩的運行一段時間
五、性能指標
怎么衡量系統的性能？以下指標
1、tps、rt、成功率
tps是用來衡量服務器的處理能力,而在jmeter中就是壓測那段時間內，總的請求數/壓測的時間=tps
rt:jmeter中有平均響應時間、90%、95%、99%的響應時間
成功率也有進行統計。
