最近在學習效能測試相關的知識，為了更加系統的來學習，特此從最基礎的講起，保證各位廣大網友看的明白，後續會不斷的記錄併產出類似的知識帖子
一、效能測試的基本概念
概念：用一定的工具，找出或者驗證某些效能指標值的測試
工具：Jmeter(主流)、loadrunner、wrk、locust、 locust是一個庫，簡稱：locust庫
特徵：多使用者併發，目標不是找bug,是看效能資料
目的：1、找出效能的指標值 （指標值：最大併發使用者數\RT\TPS\HPS\資源利用率\......等等）
在專案或者某個介面從來沒有做過效能測試時，也就是首次做效能測試，要獲取效能指標值作為基準值；當以後再次做效能測試時，可以根據這個基準值來作為判斷，效能到底是變好了還是變差了
2、驗證效能有沒有優化 通過資源的資料來判斷效能有沒有問題，有沒有優化
小提示: TPS(transactions per second):每秒鐘處理的事務數
RT(response time): 響應時間
HPS(hit per second)： 每秒鐘點選多少下
QPS(queries per second): 每秒查詢率
這些效能指標後面內容會細講
二、廣義上的效能測試
2.1 負載測試
負載測試：逐步增加併發使用者數，發起請求，找到系統的拐點區間
關鍵詞：逐步加壓 與日均訪問量有關，前提不知道能承載多少點選量，模擬不斷地增加，比如一開始設定50，然後不斷地增加使用者，看效能指標有沒有明顯的變化，那麼當效能指標值有明顯的變化時，那麼就大概的可以確定最大併發使用者數，
猜併發使用者數，怎麼來找？
比如20、40、60、每隔20的遞增，當在120的時候，效能指標正常，在140的時候，效能出現明顯的下降，那麼這個拐點區間，就在120-140之間，然後在從120開始，慢慢的遞增加1，逐步觀察效能指標值的變化，如在134是正常，135是正常出現下滑，那麼拐點就是134，基本可以斷定這個最大併發使用者數量為135
再舉個通俗的例子：你不知道你們公司的產品到底能支援多少併發使用者，怎麼取到那個最大併發使用者數量？
比如一開始都會去猜，有的猜50、100；有的猜1000、2000；那麼這與公司產品的大概的日均訪問量；比如電商淘寶網站，那麼日均訪問量幾千萬，那麼一開始設定起點，都會比較高
如果是比較小的日均訪問量，比如日均訪問量才幾千或者幾萬，那麼一開始的起點會設定的比較低；日均訪問量並不是有多少人訪問，千萬別搞錯了，哪怕一個人點選10次，那就算訪問量10，這與多少人沒有必要的聯絡，一般的公司的產品的併發量使用者都不是很高，所以在猜的時候，併發使用者一開始都是50開始。
2.2壓力測試
壓力測試：通過一定的併發使用者數，持續比較長的時間請求，檢視伺服器的穩定性
關鍵詞：比較大的壓力+比較長的時間*24 考察耐力 ---》看你能跑多長時間 不管你多少使用者，就看你在伺服器上能跑多久
舉個通俗的例子，你去跑步，腳上綁個10公斤的沙袋，看你能跑多長時間，跑的越久，說明你的耐力越好，我不管你綁多少公斤的沙袋，我只看你能跑多久；
再舉個例子，你公司有個產品，現在要做壓力測試，不管是用你們的50個併發使用者還是100個併發使用者還是200個併發使用者，我只管你用了這麼多的併發使用者，持續向你的伺服器一直不間斷的發起請求，看伺服器執行多長時間不出現崩潰或者什麼時候出現異常，看伺服器的穩定性；假如出現跑了3個小時，伺服器出現崩潰或者重啟後才能執行正常，這就說明伺服器不夠穩定；一般都會跑7*24小時（這是以前，現在一般都是跑幾個小時，比如3個小時、5個小時，8個小時類似）；很多公司在做效能測試時，一般會有個提前指標，該應用的生產環境要保證多長時間不出現問題，才算基本合格，至於跑多長時間，由公司自己定
真正的壓力測試，不能只跑幾分鐘或者只跑十幾分鍾，因為檢測的是伺服器的穩定性，必須要足夠長的時間才能大致檢測出伺服器穩不穩定
平時在公司做壓力測試，可能只跑十分鐘就夠，但那只是得到一些效能資料的資訊
先後順序：先負載測試，再壓力測試：
先做負載測試，找出最大使用者數，得到相關效能的指標，找出拐點區間，並縮小到具體的某個值
再做壓力測試，你可以用最大併發使用者數量去做，當然也並不一定要拿最大併發使用者數去做，只要比它小、不超過就行；
其實，負載測試、壓力測試，這些都是屬於廣義上的效能測試
三、效能測試的基本原則和必備條件
3.1 哪些適合做效能測試呢？
因為公司不是所有的專案都需要去做效能測試，所以哪些適合或者說可以來做效能測試呢？
1、交付型產品， 有明確要有效能測試報告的
2、涉及到錢財的、生命安全的 因為出了事責任很大，誰也擔當不起
3、大型的新系統
4、某個系統中的核心部分或者核心系統
5、架構調整 比如：jdk1.7變成jdk1.8，一些程式碼有關的比較大的調整變動
6、業務劇增 比如：雙十一，節假日等等
7、重大缺陷修復 比如：該bug的影響範圍非常廣，甚至是底層的東西
3.2 可測性
可測性：可以量化為效能指標值
比如：舉個通俗例子，問大家一個問題：
100w的使用者，某一個介面，做個效能測試，做的出來嗎？做不出來
首先，活躍使用者有多少？這100w使用者中一天有多少人來訪問？你沒有告訴我做這個效能測試，得到的是哪一個指標，是QPS還是RT還是資源利用率，並不知道；也沒給我時間要跑多久，所以很多因素確定不了，無法做效能測試，這些確定不了的東西，就要和產品經理或者架構師進行交流溝通進一步確認
假設某個介面的日均訪問量大概是500w,需要做個效能測試，怎麼來做？
日均訪問量，是白天的8小時還是24小時(問清楚，一般都是8小時)；
5000000除以24小時，再除以3600秒，那麼每秒大概處理174個請求
這174是什麼意思呢？此時可以174個人，每人一秒發一次請求 ；當然了，不一定得174個人來請求，也可以是58個人，每秒內發3次請求也可以；人數 * 每人每秒請求次數 = tps
3.3 基本原則
3.4 必備條件
1、獨立的伺服器 硬體資源相同、軟體配置相同的伺服器；如果沒有獨立的伺服器，做效能測試是做不了的
2、獨立網路 不能用有線網路 為什麼？因為有線網路不夠穩定，會造成測出來的效能資料有影響
生產環境不能被用於效能測試；為什麼？因在生產環境做效能測試，那產生的髒資料怎麼辦？如何處理？就算處理，也很麻煩；再一個做效能測試，萬一壓爆了怎麼辦?;還有如果做效能測試的過程中影響到了使用者的使用怎麼辦？這才是最重要的，所以不能用生產環境來做效能測試
四、效能測試的主要指標
1、併發/併發數/併發使用者數
併發：狹義上講：同一時間做相同事情 可以向相同的介面發起請求
廣義上講：同一時間做不同事情，混合場景 可以向不同的介面發起請求
併發數：單位時間內向伺服器發起請求的使用者數 virtual user
併發使用者數：用以模擬真實使用者向伺服器發起請求的效能測試虛擬使用者數量
系統使用者數：只要訪問過系統的使用者，包含一次性訪問的使用者 這裡做個解釋：只要訪問過，後臺伺服器有歷史記錄，那麼就算是系統使用者數
線上使用者數：當前正在訪問系統的使用者 這裡做個解釋：玩遊戲時，哪怕掛機，也算線上使用者數，因為並沒有退出
2.響應時間：從發起請求到請求響應的時間
網路傳輸時間 t1 t4
伺服器處理時間 t2 t3
3.吞吐量：是衡量 網路 的重要指標
吞吐量是指系統在單位時間內處理請求的數量，TPS、QPS都是吞吐量的常用量化指標
吞吐量 針對的是事務數 事務/s 當網路沒有瓶頸時，吞吐量的值 等於tps 的值
吞吐率 針對的是資料量 Kb/s
系統吞吐量要素，一個系統的吞吐量（承壓能力）與request（請求）對cpu的消耗，外部介面，IO等等緊密關聯。單個request，對cpu消耗越高，外部系統介面，IO影響速度越慢，系統吞吐能力越低，反之越高
重要引數：QPS(TPS),併發數，響應時間
QPS：每秒查詢率，是一臺伺服器每秒能夠相應的查詢次數，是對一個特定的查詢伺服器在規定時間內所處理流量多少的衡量標準, 即每秒的響應請求數，也即是最大吞吐能力
TPS: 每秒事務數，一個事務是指一個客戶機向伺服器傳送請求然後伺服器做出反應的過程。客戶機在傳送請求時開始計時，收到伺服器響應後結束計時，以此來計算使用的時間和完成的事務個數
併發數：系統同時處理的request/事務數
響應時間：一般取平均響應時間
關係： QPS(TPS)=併發數/平均響應時間
4.資源利用率
cpu、記憶體、磁碟、I/O
一般的普通電腦核心都是4G/8G/16G，這裡的cpu的利用率是值多核的綜合利用率，目前行業內的預設標準一般不超過80%,只要沒超過80%,說明還扛得住
所以，以上幾項都是常見的效能指標