Apache Jmeter 分佈式壓測與監控，真那麼難搞定？

1.前言

對於運維工程師來講，須要對本身維護的服務器性能瓶頸瞭如指掌，好比我當前的架構每秒併發是多少，我服務器最大能接受的併發是多少，是什麼致使個人性能有問題；若是當前架構快達到性能瓶頸了，是橫向擴容性能提高大，仍是縱向擴容性能提高大。

若是須要了解這些信息，須要在兩方面下功夫，一個是對服務器進行性能測試，一個是對服務器進行性能監控。

經過對服務器進行性能測試：咱們能夠了解到當前架構的性能瓶頸，還能夠對架構橫向擴容和縱向擴容來進行測試，對後期的架構擴容提供數據參考。

經過對服務器進行性能監控：咱們能夠了解當前服務器的CPU、內存、IO等資源是否耗盡，咱們能夠在監控系統添加觸發器，一旦服務器資源在快要達到瓶頸的時候，咱們能夠觸發一個報警讓運維人員來處理，也能夠觸發一個讓架構進行自動化擴容（若是是雲平臺，直接調用api建立主機，ansible部署應用和程序）

本文將介紹下，我在工做中使用jmeter測試性能瓶頸的一些實踐。本文作性能測試適用於移動互聯網架構，非移動互聯網架構有其餘更好的測試方法。

2.Jmeter分佈式壓測介紹

在工做中使用jmeter作大併發壓力測試的場景下，單機受限內存、CPU、網絡IO，會出現服務器壓力尚未上去，可是壓測服務器已經因爲模擬的壓力太大死機了。爲了讓jmeter工具提供更強大的負載能力，jmeter提供了多臺機器同時產生負載的機制，下面是架構圖。

原理：好比我在jmeter server配置線程數爲10，循環次數爲100，也就是會對測試服務器發起1000次請求，我有3臺agent服務器，若是我在server端選擇遠程啓動壓力測試，那麼每臺agent都會對測試服務器發起10*100次請求，那麼此次壓力測試產生的請求就是10*100*3=3000次。

若是對原理不是很明白，看完下面的操做以後就會理解了。

3.Jmeter分佈式壓測環境搭建

3.1.搭建前說明

服務器環境說明：作性能測試能夠直接在在雲平臺按需購買壓力機，一旦測試結束釋放壓力機便可。

分佈式環境壓力服務器要求：

• 須要server（控制機）和agent（壓力機），agent搭建在linux（centos 6.5）服務器環境下，server搭建在windows（server 2012）環境下。
• 壓力測試瓶頸大都在帶寬上面，須要保證壓力機的帶寬要比服務器的帶寬高，否則壓力上不去。
• 須要保證agent和server都在一個網絡中，且在多網卡環境須要保證啓動的網卡都在一個網段。
• 須要保證server和agent之間的時間同步。
• 關閉防火牆。

3.2.Windows部署jmeter

（1）部署jdk環境,配置path變量，安裝完成效果以下

（2）直接去官網下載最新的二進制源碼包便可。

（3）解壓jmeter到指定目錄，設置path變量，安裝完成以後，在命令行運行jmeter命令，若是能夠正常啓動jmeter，說明環境配置ok。

3.3.Linux部署jmeter

（1）下載安裝

wget http://mirrors.tuna.tsinghua.edu.cn/apache//jmeter/binaries/apache-jmeter-3.1.zip
unzip apache-jmeter-3.1.zip -d /usr/local/
cd /usr/local/
ln -s apache-jmeter-3.1/ jmeter

（2）配置啓動腳本

#!/bin/bash
# chkconfig: 345 26 74
# description: jmeter agent
myip=`ifconfig eth0 |awk '/inet addr/{gsub(/addr:/,"");print $2}'`
cmd="/usr/local/jmeter/bin/jmeter-server -Djava.rmi.server.hostname=$myip"

start(){  
    $cmd &
}
stop(){
   jmeter_pid=`ps aux | grep jmeter-server | grep -v grep | awk '{print $2}'`    
    for pid in $jmeter_pid;do    
    kill -9 $pid         
    done
    }
    
    act=$1
    case $act in 
    'start')   
       start;; 
    'stop')   
       stop;; 
    'restart')   
       stop   
       sleep 2   
       start;;  
    *)   
      echo '[start|stop|restart]';;
    esac

（3）啓動jmeter agent服務，驗證是否監聽1099端口

[root@jmeter-agent-01 ~]# /etc/init.d/jmeter-agent start
[root@jmeter-agent-01 ~]# netstat -lntp | grep 1099
tcp 0      0 0.0.0.0:1099        0.0.0.0:*      LISTEN 414/java

3.4.分佈式環境配置

（1）確保server和agnet安裝正確。

（2）Agent啓動，並監聽1099端口。

（3）在server機器的jmeter安裝目錄下bin目錄下，找到properties文件，修改遠程主機選項，添加3個agent服務器的地址。

（4）啓動jmeter server，多網卡模式須要指定IP地址啓動

jmeter -Djava.rmi.server.hostname=192.168.10.61

（5）驗證分佈式環境是否搭建成功

一、jmeter啓動以後在以下選項中,會出現你添加的遠程主機列表

二、建立一個請求測試：建立一個訪問百度的請求，訪問次數爲一次，配置以下：

直接點擊啓動，是jmeter server機器發起一次請求，結果以下

請求全部以前的請求數據以後，在選擇遠程所有啓動，查看發起的請求就是三次，也就是每一個agent服務器按照着server的配置，請求了一次。

若是你的環境在選擇所有啓動以後，沒有報錯，且發起請求數量和agent服務器數量一致，說明jmeter分佈式壓力測試環境搭建成功，能夠進行測試了。

4.Jmeter斷言

4.1.斷言介紹

jmeter斷言經常使用有兩種，一種是響應斷言，一種是響應時間斷言，若是響應內容不知足斷言的配置，則認爲此次的請求是失敗的。

響應斷言：判斷響應內容是否包含指定的字符信息，用於判斷api接口返回內容是否正確。

響應時間斷言：判斷響應時間，是否超過預期的時間，用於判斷api接口返回時間是否超過預期。

4.2.斷言配置

（1）修改http爲實際的api測試請求。

（2）斷言添加方式：右擊測試計劃的http請求，選擇添加à斷言à添加響應斷言和斷言持續時間。

（3）配置響應斷言：咱們接口正常返回code值爲2000，若是接口返回code值不是2000表示接口異常，爲了測試，這裏修改成接口返回code值不爲2222則表示訪問失敗。

（4）配置斷言響應時間：設置請求接口時間超過1毫秒，則認爲請求失敗。

（5）驗證斷言配置：發起http請求，因爲返回內容code值不爲2222，以及訪問時間超過1毫秒，因此認爲訪問失敗。

5.Jmeter變量配置

使用變量的場景舉例：咱們須要測試性能的曲線模型，也就是由輕壓力慢慢變爲重壓力，來測試咱們的性能拐點，這個時候jmeter就須要配置多個線程組，每一個線程組須要設置http請求，好比下圖；因爲每次測試性能的曲線模型都是同一個接口，因此每次修改接口都須要修改http請求，這個時候若是使用了變量，就意味着每次修改api只須要修改api的變量便可。

設置變量的方法：在測試計劃中

引用變量：

6.Jmeter性能測試結果分析

下面是我執行一次性能曲線模型測試（請求從每秒3千遞增到3萬）的聚合報告：簡單的看下，能夠看到性能的拐點在每秒發起2.7萬請求，TPS處理能力能夠達到6000每秒，99%的用戶響應時間在60毫秒，最大響應時間爲71毫秒，性能仍是不錯的。

併發瓶頸：當請求從每秒2.7萬遞增到3萬的過程當中，咱們的TPS由6000降低到了4500，能夠看到併發瓶頸就在每秒最多處理6000請求

響應時間：咱們能夠看到TPS保持在3500或之下，99%用戶用戶的響應時間爲11毫秒，隨着TPS的升高，咱們的響應時間也在隨着升高，能夠看到咱們的TPS在每秒3500響應的時候，對響應時間是沒有影響的。

注意這個只是個人業務其中的一個接口，咱們生產有上百個接口，不一樣的接口返回數據還有代碼邏輯，以及執行的sql均不相同，若是須要作性能測試，應該選擇其中的熱點接口，對每一個接口進行性能測試，獲得結果以後在進行具體的分析性能瓶頸到低是什麼？

聚合報告參數說明：單位爲毫秒

• Label：定義HTTP請求名稱
• Samples：表示此次測試中發出了多少個請求
• Average：平均響應時長——默認狀況下是單個request的平均響應時長
• Median：中位數，也就是50%用戶的響應時長
• 90% Line：90%用戶的響應時長
• Min：訪問頁面的最小響應時長
• Max：訪問頁面的最大響應時長
• Error%：錯誤請求的數量/請求的總數
• Throughput：默認狀況下表示每秒完成的請求數（request per second）
• KB/Sec：每秒從服務器端接收到的數據量

7.測試中的監控

7.1.併發測試監控

併發測試直接發起指定數量的請求，好比一塊兒發起10萬請求看一下系統的處理能力，這個時候若是須要服務器的資源使用信息，就不能使用好比zabbix監控系統了，由於通常處理10萬請求，對於咱們來講20秒能夠處理完畢，可是zabbix數據採集是每分鐘一次，這樣採集到的數據明顯是不許的，這樣就須要經過系統自帶的監控命令，來實時查詢服務器的性能，好比能夠經過dstat或者glances等動態監控命令來分析系統的性能。

補充：不是測試每個接口都須要進行這樣的實時監控，好比過測試個人大部分接口TPS可達5000，可是其中一個接口只能達到2000這個時候就須要在測試的時候實時監控，看一下究竟是什麼緣由致使性能上不去。是因爲返回數據太大致使網絡帶寬被佔滿；仍是sql執行時間太長致使數據庫負載高，仍是代碼有問題致使web服務cpu佔用高。

7.2.穩定性測試監控

穩定性測試就是持續不斷模擬指定數量請求，來訪問服務器，好比我每秒向測試服務器發起4000請求，持續12小時，來看看服務器會出現什麼狀況，這個時候就須要用到zabbix來進行監控了，下面是我作性能測試的部分監控接口，包含tomcat每秒請求，服務器入口流量，整個集羣每分鐘請求的http狀態碼統計，還有服務器資源使用信息。

歡迎你們關注個人微信公衆號【民工哥技術之路】，最新整理的 2TB 技術乾貨：包括架構師實戰教程、大數據、Docker容器、系統運維、數據庫、redis、MogoDB、電子書、Java基礎課程、Java實戰項目、ELK Stack、機器學習、BAT面試精講視頻等。只需在「 民工哥技術之路」微信公衆號對話框回覆關鍵字：1024便可獲取所有資料。