性能測試之入門篇

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

一、性能測試的基本概念

  概念:用一定的工具,找出或者驗證某些性能指標值的測試
  工具: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%,說明還扛得住

 所以,以上幾項都是常見的性能指標