使用Jmeter對伺服器的壓力測試
大家好，我是IT修真院北京分院第32期學員，一枚正直善良的程式設計師，今天給大家分享一下如何用Jmeter對自己的伺服器進行有效壓測，讓伺服器效果最優化：
一、Jmeter
Jmeter是一個全部程式碼由java組成的測試軟體，主要用來測試伺服器的併發數、響應時間、吞吐量，介面如下：
我們可以自己寫一些http請求，也可以使用其他輔助工具來完成指令碼的錄製，這裡推薦一款錄製指令碼軟體Badboy，匯出jmx檔案放入Jmeter軟體中可以直接出現如上圖的step1、step2，然後將就可以執行。
既然要進行壓力測試那麼我們就要明白一些引數的實際意義，
（1）Jmeter的測試引數：
執行緒數：本機與測試網站建立的連線數，因為還有一個等待時間所以執行緒數未必是順發
等待時間：我自己的理解是在X秒之後最後一個執行緒啟動，來畫一張圖理解一下：
我們可以把這些看成是我們的執行緒，在沒有迴圈的情況下，一個連結從開始到結束即收到資料之後就會停止，如果我們想保持我們的併發量，就需要設定合理的迴圈次數和等待時間，使我們的伺服器在中間一段時間內可以保持全部執行緒併發來達到一個合理的測試結果。
迴圈次數：就是每個執行緒的迴圈次數，這裡有個坑，如果你使用了badboy錄製指令碼，step中有個迴圈次數
我們需要調整這個迴圈次數而不是最開始圖上的迴圈次數，那個迴圈次數對step無效。
排程器：方便我們自動化測試指令碼，啟動時間和持續時間從字面可以理解意思，我在這裡沒有使用排程器就不妄加評論。
（2）聚合報告的引數：
samples：這個該是請求次數
average、median：平均時間和中間時間
90%line、95%line、99%line：先明確一下xx%line的含義，即百分位，如果100個請求按時間升序排列，我是第90個，那麼我請求的時間就是90%，翻譯過來就是有90%的資料花費的時間比我的少，這個指標代表了高併發情況下大部分使用者的體驗值
min、max：最短耗時和最長耗時 也就是第一位和第一百位，以上時間均以毫秒位單位
error：狀態碼不為200的請求（錯誤請求），原因有很多，可以具體檢視。
throughput：吞吐量，每秒鐘處理請求的次數
recieved kb/s：獲得的資料量
比較重要的是90%line、error、throughput，我們在做壓力測試的時候要根據伺服器和網頁的實際情況，不只根據資料還要根據伺服器的效能來做出各種調整，需要注意的是不是tps越高越好，也不是90%線越快越好，因為這無法代表你伺服器的最佳狀態，引數需要多次調式之後才能獲得正確聚合報告。
（3）Jmeter的外掛
Jmeter自帶的一些影象可能無法滿足我們的需求，這裡可以使用Jmeter的外掛，Jmeter Plugins下載一些方便我們測試的外掛，如下圖：
在此測試中我主要使用的是聚合報告、[email protected] - Transactions per Second和結果樹三個報告。
二、實際測試
下面是我要測試的三個頁面：
主頁：主頁包含大量的靜態檔案，極少的和資料庫互動的動態資料，只有4個隨機選取展示學生會比較浪費時間。
學生列表頁面，此頁面無靜態資源、直接從資料庫拿出一個100資料的大list。
學生查詢頁面，此頁面只有一組資料，memcached進行的是key-string快取、redis進行的是key-map快取。
（1）主頁壓測結果：
無快取、無動靜分離，無負載均衡：
memcached快取、有動靜分離、無負載均衡（15執行緒、20迴圈、4次樣本）：
伺服器頻寬情況：
memcached快取、有動靜分離、有負載均衡（15執行緒、20迴圈、4次樣本）：
伺服器頻寬情況：
redis快取、有動靜分離、有負載均衡（15執行緒、20迴圈、4次樣本）：
top指令檢視伺服器記憶體、CPU佔用情況：
伺服器頻寬情況：
redis快取、有動靜分離、無負載均衡（15執行緒、20迴圈、4次樣本）：
伺服器（1M）頻寬情況：
redis快取、有動靜分離、有負載均衡（15執行緒、20迴圈、4次樣本）：
（2）學生列表（100個）壓測結果：
無快取、無負載均衡（15執行緒、20迴圈、4次樣本）：
memcached快取、有負載均衡（15執行緒、20迴圈、4次樣本）：
伺服器（1M）頻寬情況：
memcached快取、無負載均衡（15執行緒、20迴圈、4次樣本）：
伺服器（1M）頻寬情況：
redis快取、無負載均衡（15執行緒、20迴圈、4次樣本）：
redis快取、無負載均衡（20執行緒、20迴圈、1次樣本）：
伺服器（1M）頻寬情況：
redis快取，有負載均衡（15執行緒、20迴圈、4次樣本）：
伺服器（1M）頻寬情況：
（3）查詢單個學生壓測結果：
無快取、無負載均衡（20執行緒、50迴圈、6次樣本）：
memcached快取，無負載均衡（20執行緒、50迴圈、6次樣本）：
伺服器（1M）頻寬情況：
memcached快取，有負載均衡（20執行緒、50迴圈、6次樣本）：
伺服器（1M）頻寬情況：
redis快取，無負載均衡（20執行緒、50迴圈，6次樣本）：
伺服器（1M）頻寬情況：
redis快取、有負載均衡（20執行緒、50迴圈、6次樣本）：
伺服器（1M）頻寬情況：
測試總結：
在合適的執行緒*迴圈數的情況下伺服器頻寬均能跑到0.9-1.1，這裡也是一個最大的瓶頸，網路因素也最大程度的影響了測試結果，下面分析一下測試報告：
（1）主頁
由於主頁的特殊性，快取與否影響不大，甚至可能會造成速度減慢，重點應該放在負載均衡與動靜分離的處理上：
此處沒有做無動靜分離的情況，因為一開始沒有動靜分離15*20有的時候都跑不完。
如上圖所測，在無負載均衡的情況下，吞吐量只有1.8，每秒接受資料量33.26，90% 2138
在有負載均衡的情況下，吞吐量均達到了5以上，每秒接受資料量90-100，然而90%變慢，相應的90%-100%之間的速度大大提升，速度加快一倍
結論：在大量靜態頁面+少量動態資料的構成頁面中，我們可以只配置動靜分離+負載均衡就能大幅度的提高伺服器吞吐量，但是90%線會稍微變慢，相應的，90%-100%速度會大幅度加快，而快取對這種頁面影響十分小。
（2）100個物件的list
無負載均衡、無快取：90% 3244 TPS：2.9
無負載均衡、memcached快取：90%：2273 TPS:5.2
無負載均衡、redis快取：90%：2195 TPS：5.0
可以看出快取的效果，90%線減少，TPS增大明顯，但是這裡有一點要說，雖然redis快取90%線低於memcached90%線，但是90%-100%的處理時間要比memcached稍微長一些，不能排除是網路因素導致。
負載均衡對此處的影響：
memcached：90%增加，95%增加，99%減少，吞吐量5.2-5.8，略微增加
redis：90%不變，95%不變，99%減少，吞吐量5.0-4.7，略微減少
結論：在查詢大量資料的時候，應該使用快取，但是也要考慮快取序列化與反序列化消耗的時間，也要善於利用redis的map儲存特性，負載均衡對此處影響不大，而且網路有波動會對測試結果造成很大的影響，不能斷言負載均衡的效果，結合伺服器的負載情況，當開啟兩個tomcat部署專案的時候記憶體消耗分別為30%和20%應該還有很大提升空間，但是受限於1M頻寬。
（3）單獨查詢一個學生
無負載均衡無快取：90%：218 TPS：104.3
memcached快取：90%：219 TPS:118
redis快取： 90%：224 TPS：62
結論：此處redis做了map快取導致pojo類和map類轉換（反射過程）消耗了大量時間，tps明顯降低，而使用memcached則是直接儲存String型別，90%無變化（數值太小）,TPS略微上升，對小資料的快取我們應該謹慎使用，但是還是建議使用redis和memcached的普通型別儲存，而不建議使用map。
負載均衡對此處的影響：
memcached:90%線無變化，TPS降低
redis：90%線無變化,TPS上升：62.2-84.7
結論：負載均衡下分擔了POJO-MAP及MAP-POJO的轉換壓力，加快了速度，但是吞吐量還是比不上直接儲存的速度，但是memcached這個降低沒太搞懂。
（4）快取穿透：模擬失敗，設定為空的時候查詢不存在的key，90%線差不多為40，TPS200多，但是沒有穿透情況下的資料，原因為各種環境因素制約。
（5）在維護資料的同時查詢：由於沒有使用互斥鎖，查詢到了髒資料的情況。