ID：jishuroad
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）驗證分佈式環境是否搭建成功
1、jmeter啟動之後在如下選項中,會出現你添加的遠程主機列表
2、創建一個請求測試：創建一個訪問百度的請求，訪問次數為一次，配置如下：
直接點擊啟動，是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狀態碼統計，還有服務器資源使用信息。
【年薪30w工程師吐血整理資料大合集】
領取IT資料大合集：http://image.qbangmang.com/counselor.html
閱讀更多 馬哥Linux 的文章
