性能測試之入門篇

最近在學習性能測試相關的知識，爲了更加系統的來學習，特此從最基礎的講起，保證各位廣大網友看的明白，後續會不斷的記錄併產出相似的知識帖子

1、性能測試的基本概念

　　概念：用必定的工具，找出或者驗證某些性能指標值的測試
　　工具：Jmeter(主流)、loadrunner、wrk、locust、 locust是一個庫，簡稱：locust庫
　　特徵：多用戶併發，目標不是找bug,是看性能數據
　　目的：一、找出性能的指標值 （指標值：最大併發用戶數\RT\TPS\HPS\資源利用率\......等等）
　　　　　　　　　　　　在項目或者某個接口歷來沒有作過性能測試時，也就是首次作性能測試，要獲取性能指標值做爲基準值；當之後再次作性能測試時，能夠根據這個基準值來做爲判斷，性能究竟是變好了仍是變差了
　　　　　二、驗證性能有沒有優化 經過資源的數據來判斷性能有沒有問題，有沒有優化
　　小提示:  TPS(transactions per second):每秒鐘處理的事務數
　　　　　　RT(response time): 響應時間
　　　　　　HPS(hit per second)： 每秒鐘點擊多少下
　　　　　　QPS(queries per second): 每秒查詢率

        這些性能指標後面內容會細講

2、廣義上的性能測試

　　

　　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、性能測試的基本原則和必備條件

　　3.1 哪些適合作性能測試呢？

　　由於公司不是全部的項目都須要去作性能測試，因此哪些適合或者說能夠來作性能測試呢？
　　一、交付型產品，  有明確要有性能測試報告的
　　二、涉及到錢財的、生命安全的      由於出了事責任很大，誰也擔當不起
　　三、大型的新系統
　　四、某個系統中的核心部分或者核心系統
　　五、架構調整   好比：jdk1.7變成jdk1.8，一些代碼有關的比較大的調整變更
　　六、業務劇增   好比：雙十一，節假日等等
　　七、重大缺陷修復   好比：該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  必備條件

　　　　一、獨立的服務器 硬件資源相同、軟件配置相同的服務器；若是沒有獨立的服務器，作性能測試是作不了的
　　　　二、獨立網絡  不能用有線網絡 爲何？由於有線網絡不夠穩定，會形成測出來的性能數據有影響

　　　　生產環境不能被用於性能測試；爲何？因在生產環境作性能測試，那產生的髒數據怎麼辦？如何處理？就算處理，也很麻煩；再一個作性能測試，萬一壓爆了怎麼辦?;還有若是作性能測試的過程當中影響到了用戶的使用怎麼辦？這纔是最重要的，因此不能用生產環境來作性能測試

4、性能測試的主要指標

一、併發/併發數/併發用戶數
併發：狹義上講：同一時間作相同事情 能夠向相同的接口發起請求
　　    廣義上講：同一時間作不一樣事情，混合場景 能夠向不一樣的接口發起請求
併發數：單位時間內向服務器發起請求的用戶數 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%,說明還扛得住

 因此，以上幾項都是常見的性能指標

 

 

本文連接：https://www.cnblogs.com/xj-excellent/p/14022238.html，未經本人容許，禁止轉載；如若侵權，一定追究；本帖爲做者原創，請尊重版權