點選上方“民工哥技術之路”選擇“星标”
每天10點為你分享不一樣的幹貨
讀者福利！多達 2048G 各種資源免費贈送
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端口
[[email protected] ~]# /etc/init.d/jmeter-agent start
[[email protected] ~]# 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狀态碼統計，還有伺服器資源使用資訊。
版權申明：作者：西門飛冰，一名90後it男，一直在北京工作，熱愛運動，熱愛冒險，熱愛旅行。原文：http://www.fblinux.com/?p=951，由作者原創投稿，版權歸原創者所有。除非無法确認，我們都會标明作者及出處，如有侵權煩請告知，我們會立即删除并表示歉意，謝謝。
關注 民工哥技術之路 微信公衆号對話框回複關鍵字：1024 可以擷取一份最新整理的技術幹貨：包括系統運維、資料庫、redis、MogoDB、電子書、Java基礎課程、Java實戰項目、架構師綜合教程、架構師實戰項目、大資料、Docker容器、ELK Stack、機器學習、BAT面試精講視訊等。
生鮮電商“呆蘿蔔”欠薪300人，P9高管劉某嘴臉醜惡！據傳有2.9億的大窟窿..
火了！還真有大神把地府背景管理系統做出來了，“閻王爺”瘋狂點贊！
牛逼哄哄的ELK日志分析系統，搭建起來也沒有想象中的那麼難啊...
如何一眼看穿一家公司要涼？
漫談四種主流軟體架構演進史
ROW 還是 STATEMENT？線上MySQL Binlog怎麼選？
點選【閱讀原文】發現更多精彩内容~~
在看的你，請點這裡↓↓↓