利用jmeter進行壓力測試

jmeter進行壓力測試

推薦博客：jmeter  http://www.cnblogs.com/fnng/category/345478.html

　　　　　 http://www.cnblogs.com/puresoul/category/736960.html

　　　　　javavirtualVM 遠程  https://my.oschina.net/sub/blog/223475

　　　　　插件 http://blog.csdn.net/defonds/article/details/54576604

　　　　　調度器  http://blog.csdn.net/java2013liu/article/details/53424545

1.壓力測試的簡單講解

2.壓力測試的指標、監控

3.利用jmeter進行壓力測試

4.壓力測試瓶頸的簡單定位

 

1.壓力測試的簡單講解

　　（1.）何時進行壓力測試。

　　　　基於接口的壓力測試，在接口功能測試完成以後就可進行接口的壓力測試。若是有接口的依賴關係，各個接口都要完成接口的功能測試以後，再行壓力測試

　　　　基於業務多場景的綜合壓力測試，要在全部業務功能測試經過以後進行

　　 (2.) 壓力測試的合理性

　　　　壓力測試結果是否有效，還要看壓力環境，舉個例子： 測試環境和生產環境硬件配置沒可比性，那麼測試環境的壓力測試毫無心義，測試報告毫無心義

　　　　在沒法保證測試環境生產環境相同的配置狀況下，理論要求: 單機配置相同。再舉個例子：正式環境服務器10臺 16G 4核  數據庫 5臺   那麼測試環境 1臺 4核 16G的服務器，數據庫服務器也要和生產單臺配置相同

　　　　若是有條件能夠在生產環境直接進行壓力測試

2.壓力測試的指標　　　

一、吞吐率（Request per second)

服務器併發處理能力的量化描述，單位是reqs/s,指的是某個併發用戶數單位時間內處理的請求數。某個併發用戶數下單位時間內能處理的最大請求數，稱之爲最大吞吐率。

記住：吞吐率是基於併發用戶數的。這句話表明，1：吞吐率和併發用戶數相關；2：不一樣的併發用戶數下，吞吐率通常是不一樣的。

計算公式：總請求數/處理完成這些請求數所花費的時間。

Request per second=Complete requests / Time Taken for tests

二、併發鏈接數（The number of concurrent connections)

併發鏈接數指的是某個時刻服務器所接收的請求數目，簡單的講，就是一個會話。

三、併發用戶數（The number of concurrent users,Concurency Level)

要注意區分這個概念和併發鏈接數之間的區別，一個用戶可能同時會產生多個會話，也即鏈接數。在Http/1.1下，IE7支持兩個併發鏈接，IE8支持6個併發鏈接，FireFox3支持4個併發鏈接，因此相應的，咱們併發用戶數就得除以這基數。

四、用戶平均請求等待時間（Time per request)

計算方式：處理完成全部請求數所花費的時間/(總請求書/併發用戶數），即

Time per request=Time Taken for tests/(Complete reuqests/Concurrency Level)

5:服務器平均請求等待時間（Time per request:across all concurrent requests)

計算公式：處理完成全部的請求數所花費的時間/總請求數，即

Time taken for/testsComplete requests

能夠看到，它是吞吐率的倒數。

同時，它也等於用戶請求等待時間/併發用戶數，即

Time per request /Concurrency Level

 3. 利用jmeter進行壓力測試

　　1.參數化  2.關聯   3.jmeter基本介紹  4.監控   5.測試報告

　　@@@參數化@@@

在作測試時，造的測試數據要有本身的標識，便於之後刪除或查找問題，好比：yxjtest001

對於LR或jmeter而言，本身輸入的值頂多須要作參數化

參數化緣由：
1.逼不得已（應用程序不容許反覆操做、數據庫校驗惟一性）
2.避免數據庫的查詢緩存
緣由：若使用線上(已有)數據或沒有參數化，會致使測試結果失真。

查詢緩存：

偷懶：
1.若數據量較大，可暫時把數據庫校驗惟一性去掉
2.爲了消除緩存影響，可把數據庫緩存(cache)關掉(對於select操做)

銀行流水號-------參數化
100個併發用戶，併發10分鐘，tps=10，1個用戶跑基準測試，tps=1
Q：參數化設置？
A：那麼平均給每一個用戶分配60個值，可是建議60以上好比80
(10*10*60/100=60，至少須要造的數據：60*100=6000)

銀行流水號-------參數化
100個併發用戶，併發10分鐘，tps=?(無限)，1個用戶跑基準測試，tps=1
Q：參數化設置？
A：那麼平均給每一個用戶分配600個值，可是建議600以上好比800
(一個用戶10分鐘跑的事務：1*10*60=600，至少須要造的數據：600*100=60000)

關聯函數放在距離最近的能夠返回關聯的值的那個請求的前面

　　　　@@@關聯@@@

將服務器返回的動態的變化的值，把他保存爲一個參數，以供後面須要使用它的地方進行使用。

何時須要作關聯：
1.服務器會校驗該值的合法性【hash、cookie、session、token、時間戳、驗證碼（圖片驗證碼、短信驗證碼、郵箱驗證碼）】
遇到 驗證碼 時，寫js去本身解析驗證碼，而後再使用；
或者把驗證碼驗證去掉（或整個萬能驗證碼）
2.數據庫打交道--後續須要對該值進行增刪改查操做（此狀況用的比較多）
insert操做---插入的值須要與其餘表的數據創建關聯/對應關係，須要進行關聯

腳本回放成功，只是表明http狀態碼成功

查看關聯函數放在哪兒，能夠：
1.鼠標放在不肯定放在哪兒的腳本中，點擊 tree-->http View 查看response
2.抓包看，找要關聯的變化的值，看其在哪一個URL（即哪一個URL會返回該值）
3.點擊 Run-time setting-->Log-->勾選 Data returned by server
4.看腳本下方的 Generation Log

關聯函數添加：
1.進入Tree 模式，response下，找到要關聯的值-->右鍵 Create Parameter
（此種方式關聯的位置是對的，且會自動把左右邊界找好，可是有可能左右邊界值會錯，因此須要回放看一下）
2.右鍵 insert-->new step （或者 alt+insert）||直接點擊頁面頂部的 insert-->new step
3.直接從response裏面找
4.抓包，看裏面的左右邊界值
5.經過查看源文件，找左右邊界值

>若是不轉義，回放時系統會默認是HTML語言的一部分，進而把其忽略掉

若是左右邊界設置的值不是很精確的話（即好多地方不一樣的內容都匹配），系統默認取第一個取到的值，如果第一個值匹配的話還好，不匹配的話就會報錯。

若是想要關聯的值出現的次數較多，不肯定取哪一個值的左右邊界時，建議取出現次數較多的。

批量替換：ctrl+h

【例子：】
登錄天貓----查看首頁----瀏覽商品---商品添加購物車---修改商品信息----刪除不要的商品---支付---查看訂單--刪除訂單

登錄----可能須要參數化----select

查看首頁--理論不須要參數化關聯，精準推薦時候須要關聯----select

瀏覽商品---有可能參數化 有可能關聯 ----都是產品id----select

添加購物車---關聯 商品id 用戶id insert

修改商品信息---關聯 商品id 用戶id update

刪除商品-----關聯 商品id 用戶id delete

支付-----insert訂單 關聯 訂單id 用戶id delete刪購物車 關聯商品id 用戶id update 修改庫存 商品id

查看訂單----關聯select 訂單id

刪除訂單-----delete 關聯 訂單id

 　　　　@@@jmeter基本使用@@@

啓用 調度器，則 循環次數 不生效

CSV Date Set Config中Allow quoted data?設置 True時取的值沒有引號；設置 False時取的值有引號

CSV Date Set Config中Sharing mode----All threads：標準的 惟一 + 每次迭代
線程組與線程組之間取值也不同，嚴格遵循惟一
CSV Date Set Config中Sharing mode----Current thread：標準的 順序 + 每次迭代
不一樣線程組之間也是順序的
CSV Date Set Config中Sharing mode----Current thread group：基於每一個線程組下的 惟一 + 每次迭代
不一樣線程組之間是順序的，平行取值

Loadrunner與Jmeter相比，Loadrunner靠譜。
Loadrunner響應時間比Jmeter小，由於是C寫的。
小規模併發，jmeter響應時間比LR小一些，理論上LR響應時間比jmeter短，全部要加檢查點，看請求是否都成功。
大規模併發，jmeter響應時間比LR大。

 

LR關聯有5種方法：
tree視圖response中找
tree視圖裏郵件自動關聯
lr日誌裏找返回值
抓包
chrome中F12
查看源文件

Python最少學到IO操做

第1種自動化：測試工具的開發
第2種自動化：測試平臺的開發

在作性能壓測的時候，查看結果樹通常被禁用，此時能夠加【斷言結果】，以此來查看請求是否成功。
【響應斷言】結果在查看結果樹裏看

Jmeter中Think-time能夠靠添加【定時器】來實現

Jmeter中集合點能夠靠添加【Synchronizing Time】來實現

Jmeter查看報告的話，看【聚合報告】

跟隨重定向，會記錄整個請求過程，包括cookie跟header，自動重定向不會。

數據庫鏈接池有2個，一個是MySQL容許的最大值，一個是應用程序容許的。主要是看應用程序容許的最大值是多少。
好比Jmeter中要看ax Number of Connections設置的值

開發測試的值跟你的不同（響應時間比你測的少，TPS比你的大）？
先肯定軟件/硬件環境、數據庫裏的數據量是否一致，用的測試工具是否一致？
ab或webbench不接收服務器返回值，可是LR跟jmeter會接收服務器返回值，因此會不同。
即便用相同的工具，得出的值也會有所差別，可是不會差不少，能夠取平均值。

工具裏的響應時間是1.9秒，可是日誌裏響應時間是1.8秒？
先肯定大家的響應時間是否是指的【同一個】請求，由於工具裏給的時間有多是多個請求的。

假設開發跟你看的都是一個請求，可是響應時間的值不同，是什麼緣由？
開發計算的起始結束時間與你的不同，你的話能夠從負載機、網絡、中間件排查是否哪裏中出了問題。

　　　　　　@@@監控@@@@

CPU使用率高怎麼辦？
top命令看下CPU使用狀況，而後按1看下是否全部的CPU都高，而後再看是因爲剛併發致使的仍是併發一段時間後出現了該現象
接着看究竟是用戶態進程佔用CPU高仍是系統態進程佔用CPU高，若是是user佔用高則說明用戶進程消耗了，
去查看高的進程（top），再去看進程對應的線程及執行的請求；
若是是系統態佔用CPU高，說明系統內核調用致使了CPU比較高，
看是不是因爲磁盤繁忙（sar、nmon--discuss busyness）致使的，
若是是磁盤的話再看是讀仍是寫致使的，如果讀（磁盤往內存裏讀）說明有多是內存不足致使的，
如果寫操做比較高看下是誰在寫操做，查看下當前系統在寫什麼而後減小下寫操做
若是不是由磁盤引發的，使用命令strace看系統調用的哪一個內核，

總結(CPU消耗高定位)：
top 找出消耗最高的進程pid
top -H -p pid （找出最高的線程tid）
printf "%x\n" tid 線程tid轉換成16進制B
而後拿着B去jstack dump出來的文件（nid）裏查對應的方法
或者 jstack pid | grep 轉換成的16進制

 

用戶態cpu：用戶進程作的事
系統態cpu：任何觸發內核調用的

進程狀態：running、終端可恢復狀態、中斷不可恢復狀態、殭屍進程

top: load average-->指系統正在排隊的進程已經進行的進程，簡單來講就是系統負載
（系統過去1分鐘的平均負載、系統過去10分鐘的平均負載、系統過去15分鐘的平均負載）
查看cup顆粒數-->top後按1 或 cat /proc/cupinfo
Cpu(s)-->指平均CPU使用狀況，不會超過100% || 可是Cpu卻可能超過100%
Swap-->指虛擬內存
NI：指CPU運行進程的優先級
按CPU排序：shift+P
按內存排序：shift+M

load average:load---等待IO的進程+等待CPU處理的進程

CPU低，負載高狀況：
IO操做進程比較多，等待IO的進程多
數據庫全表掃描（沒有索引時），由於數據不在內存在磁盤中，要從磁盤中那數據

存活區大約是大小相等，位置互換

YGC時執行2件事：
①. 尋根判斷，判斷哪些是垃圾對象，哪些是存活對象(沒有引用的對象屬於垃圾對象，還有引用的指向屬於存活對象)。
②. 進行垃圾回收，把存活對象放到第一個存活區，把垃圾對象回收。(在進行垃圾回收時，整個應用程序的線程是暫停的。)

年輕代(僅僅供參考下，不全)：
串行回收：java應用線程中止，用1顆CPU進行回收
並行回收：java應用線程中止，用多顆CPU進行回收

YGC只會發生在伊甸園區（伊甸園區觸發YGC），可是YGC做用的範圍是伊甸園區+存活區。

如下會進入老年代區：
1.大對象
2.長期存活的對象（默認age=15-->GC15次）
3.對象動態分配（survivor空間中相同年齡的對象的大小總和大於survivor空間的一半，則從該age及以上都會晉升到老年代）

老年代滿了會觸發FGC，可是年輕代與老年代不一樣時作GC。

什麼狀況下會致使FGC？
1.定位內存泄漏用 jmap -dump的時候會觸發FGC
2.老年代內存不足的時候
3.持久代被寫滿
4.System.gc()被顯示調用
5.上一次GC以後Heap的各域分配策略動態變化

若是有大量的FGC就要查詢是否有內存泄漏的問題了，若FGC數量比較大而且執行時間較長，就會致使系統的響應時間較長。

Full GC:
對整個堆進行整理，包括年輕代、老年代和持久代。
Full GC由於須要對整個堆進行回收，因此比YGC要慢（且會頻繁佔用線程），所以應該儘量減小、延緩FGC（老年代）的次數。

GC時，java應用線程是中止的，回收以後應用程序纔會繼續

jmap:分析內存泄漏，dump內存使用狀況的
jmap -heap pid
jmap -histo pid 內存調用狀況（能定位到方法級），若前幾個沒有本身認識的方法，
用MAT把內存信息dump下來
jmap -histo:live pid 內存中還在引用的對象
jmap -dump:live,format=b,file=XX.bin pid 能夠dump堆內存使用快照
jmap -dump 的時候會進行(觸發)FGC

jstat監視垃圾回收活動狀況,看YGC時間是否是太長，FGC的頻率是否過高，從而對代碼進行優化
jstat -gcutil pid 2000 ---2秒刷新一下數據

jstack:把棧區dump下來,分析線程棧的時候：
先搜索是否有blocked（死鎖）狀態(若有blocked看死鎖的線程執行的方法，進而找出緣由)
再看waiting狀態(看waiting線程執行的方法，進而找出緣由)
再看running，像什麼CPU高就是running形成的
jstack pid

總結(CPU消耗高定位)：
top 找出消耗最高的進程pid
top -H -p pid （找出最高的線程tid）
printf "%x\n" tid 線程tid轉換成16進制B
而後拿着B去jstack dump出來的文件（nid）裏查對應的方法
或者 jstack pid | grep 轉換成的16進制

 

線程ID轉換爲16進制格式：
printf "%x\n" tid

線程常見幾種狀態：runnable running wating sleeping blocked dead
進程幾種狀態：running 中斷可恢復狀態 中斷不可恢復狀態 殭屍進程

硬件緣由，好比CPU滿或者負載很是高
用top命令查看cup、load average；iostat查看IO信息--若tps很低則表明IO沒問題

【【日誌要實時看，出了問題先看日誌再使用top命令排除完硬件緣由後，應該立刻用jstack去看下線程棧】】
1.jstack 應用pid > XXX.log
2.看線程棧：vi XXX.log
3.搜索：/BLOCK 死鎖緣由在 at 後

數據庫死鎖：表如今mysql裏面block
線程池死鎖：在線程池裏面的鎖就是線程池死鎖

Jmeter 比 LoadRunner快的緣由：Jmeter有個長鏈接可勾選(User KeepAlive)

JVM參數--JVM內存大小默認64M好像是

定位內存泄漏最快的方式是用jmap
1.jmap -histo pid 內存調用狀況（能定位到方法級），若前幾個沒有本身認識的方法，就用MAT把內存信息dump下來
2.jmap -histo pid > 1.txt
3.查看 1.txt，若在前20中沒有發現認識的包/方法，就先dump一份(jmap -dump:live,format=b,file=XX.bin pid 能夠dump堆內存使用快照)
4.而後sz XX.bin文件到Windows環境上，用MAT或jhat分析dump的文件，通常用MAT
5.使用MAT打開後會有2個窗口，不要看視圖(Overview)而是先看報告就行

jmap -dump 的時候會進行(觸發)FGC

jvisualvm dump的文件後綴是：.hprof

linux部署項目時，.war文件通常會自動解壓，若系統沒有給自動解壓就用unzip手動解壓便可

 

 

 

 

 

 

掌握JVM垃圾回收原理，可以熟練使用jmap、jstack、jhat、jstat、jconsole、jvisualvm、jprofiler 進行性能監控、問題定位及Java虛擬機的問題優化