jmeter常用的監聽器

jmeter常用的監聽器

jp@gc - Bytes Throughput Over Time:不同時間吞吐量展示（圖表） 
聚合報告里，Throughput是按請求個數來展示的，比如說1.9/sec，就是每s發送1.9個請求；而這里的展示是按字節Bytes來展示的圖表

jp@gc - Composite Graph： 混合圖表 

在它的Graphs里面可以設置多少個圖表一起展示，它可以同時展示多個圖表

jp@gc - Hits per Second：每秒點擊量

jp@gc - PerfMon Metrics Collector：服務器性能監測控件，包括CPU，Memory，Network，I/O等等

jp@gc - Reponse Latencies Over Time：記錄客戶端發送請求完成后，服務器端返回請求之前這段時間

jp@gc - Reponse Times Distribution： 顯示測試的響應時間分布，X軸顯示由時間間隔分組的響應時間，Y軸包含每個區間的樣本數

jp@gc - Transactions per Second： 每秒事務數，服務器每秒處理的事務數

jp@gc - Reponse Times vs Threads：展示事務響應時間與虛擬用戶數之前的對應關系

 

 

服務器性能分析：

cpu:

CPU 在操作系統中是運行的根本,CPU的執行速度與性能好壞在很大程度上決定了系統整體的性能的快慢,最開始大部分任務是單線程調度,CPU在同一時間內只能運行一個線程,但隨着多處理器技術的成熟,軟件架構的深入和復雜度的提升,單處理系統組件在往多處理系統轉變,這些都是利用處理器的多核心處理能力的特性來提升系統性能.在做系統性能分析前,首先我們要了解系統處理器的情況,如邏輯處理器,處理器型號,主頻率,cache大小,是否支持超線程技術等信息,在知道這些的情況下,才能更好地進行我們系統的性能分析.

除此之外,CPU的使用率也是我們需要關注的很重要指標,當CPU處於滿載狀態時,很多時候我們要結合系統附帶的一些系統監控分析工具,檢查相關的系統日志,web服務器日志,DB日志等,結合輔助一些命令如top,free,uptime,sar等輔助分析為什么系統CPU會被完全占用,以及后續的解決優化方案.

memery：內存

在系統性能因素中,內存大小也是影響系統性能的一個非常核心的指標,當可用的內存太小,系統進程會被阻塞中,應用也將會變得非常緩慢,有時候會失去響應,嚴重的甚至可能會觸發系統的OOM(內存溢出)從而引發應用程序被系統給殺死,更嚴重的情況可能會引起系統重啟;當機器的內存太大的時候,有時候也是一種浪費,這時候我們可以考慮做一些緩存服務去提升系統性能.

虛擬內存也是在內存里面我們需要考慮的性能指標,在系統設計中,當系統的物理內存不夠用的時候,就需要將物理內存中的一部分空間釋放出來,以供當前運行的程序使用.那些被釋放的空間可能來自一些長時間沒什么操作的程序,這些被釋放的空間被臨時保存到虛擬內存空間中,等到那些程序要運行時,再從虛擬內存中恢復保存的數據到物理內存中.這樣,系統總是在物理內存不夠時,才進行內存之間的交換,有時可以越過系統性能瓶頸,節省系統升級費用.在做性能分析的時候,我們也要考慮系統有無設置虛擬內存,以及虛擬內存的使用情況.

內存分析

Mem:232600k,total	物理內存總量
Mem:224688k,used	使用的物理內存總量
Mem:7912k,free	空閑內存總量
Mem:8508k,buffers	用作內核緩存的內存量
Mem:46264,cached	緩沖的交換區總量
Swap:209714k,total	交換區總量
Swap:62052k,used	使用的交換區總量
Swap:2035092k,free	空閑的交換區總量

swap:交換分區

DIsks I/O:硬盤

訪問應用離不開系統的磁盤數據的讀寫,I/O讀寫的性能直接會影響系統程序的性能.讀寫的性能直接會影響系統程序的性能,磁盤I/O系統是系統中最慢的部分.I/O比較頻繁的時候,如果I/O得不到滿足會導致應用阻塞.針對I/O的場景模型,我們要考慮的有I/O的TPS,平均I/O數據,平均隊列長度,平均服務時間,平均等待時間,IO利用率等指標.

network I/O :網絡

系統應用之間的交互,尤其是跨機器之間的,都是要基於網絡的,因此網絡寬帶,響應時間,網絡延時,阻塞等都是影響系統性能的因素.假如應用在不穩定和不安全的網絡下會導致應用程序的超時,丟棄,阻塞,波動率大,這些在系統中都是不能接受的.我們需要一個可靠的,穩定的,能滿足我們應用程序在機器之間暢通無阻地運行,這些需要測試工程師,網絡管理員,系統管理員等一起合作把系統的網絡完善.

在系統中,我們要考慮對應的網絡是否可達,防火牆是否開啟,端口訪問,帶寬是否有被限制,路由的尋址,網絡的延時等問題.

TCP：一種網絡傳輸協議

JMX：

EXEC:

TALL：

 

模塊	類型	度量方式	衡量標准
CPU	使用情況	1.vmstat 統計l-id 的計數 2.sar-u 統計l-%idle的計數 3.dstat命令 統計 l-idl的計數 4.mpstat-PALL 統計 l-%idle的計數 5.ps命令統計cpu的計數	注意≥50% 告警≥70% 嚴重≥90%
CPU	滿載	6.vmstat 的 r 計數 >CPU邏輯順數 7.sar –q,”runq-sz”>CPU邏輯順數 8.dstat –p,”run”>CPU邏輯順數	運行的隊列大於1時,證明已經有一定的負載了,不過這個計數也不絕對,需進一步分析其他的資源情況來斷定CPU是否已滿載負荷運作
CPU	錯誤	9.通過perf工具去捕獲處理器的錯誤信息,需處理器支持	需處理支持
內存	使用情況	1.free命令查看使用情況 2.vmstat命令查看使用情況 3.sar-r命令查看使用情況 4.ps命令查看使用情況	注意≥50% 告警≥70% 嚴重≥90%
內存	滿載	5.vmstat的 si/so 比例輔助swapd 和free 利用 6.sar-W 查看每次缺頁數 7.查看內核日志有無OOM 機制kill 進程 8.dmesg|grep killed	1.so數值大,且swapd已經占比很高,內存肯定已經飽和 2.sar命令次缺頁多意味已經在不停地和swap打交道,證明內存已經飽和 3.當內存不夠用會觸發內核的OOM機制
內存	錯誤	9.查看內有無physical failures 10.通過工具如valgrind 等進行檢查	有計數
網絡	使用情況	1.sar –n DEV 的收發計數大於網卡上限 2.ifconfig RX/TX 寬帶超過網卡上限 3.cat/proc/net/dev/ 的速率超過上限 4.nicstat的util 基本滿負荷	1.收發包的吞吐速率達到網卡上限 2.有延遲 3.有丟包 4.有阻塞
網絡	滿載	5.ifconfig dropped 有計數 6.nestat-s”segments retransimted”有計數 7.sar-n EDEV rxdrop txdrop 有計數	統計的丟包有計數證明已滿載了
IO	使用情況	1.iostat –xz,”%util” 2.sar-d,”%util” 3.iotop的利用率很高 4.cat/proc/pid/sched|grep jowait	注意≥50% 告警≥70% 嚴重≥90%
IO	滿載	5.iostat –xnzl,”avgqu-sz”>1 6.iostat await>70	IO 已經有滿載嫌疑
IO	錯誤	7.dmesg 查看io錯誤 8.smartctl/dev/sda	有信息

 

系統負載監控分析實踐

uptime命令:主要用於獲取主機運行時間和查詢Linux系統負載等信息,uptime命令可以顯示系統已經運行了多長時間,以及有多少用戶登錄,快速獲取服務器的負荷情況,它信息顯示依次為:現在時間,系統已經運行了多長時間,目前有多少登錄用戶,系統在過去的1分鍾,5分鍾,15分鍾內的平均負載.

1.uptime的系統存活時間越長,意味着系統穩定,我們可以通過uptime查看系統這一段時間有無重啟,這也是一種常見分析系統是否穩定的命令

2.通過uptime命令可以得知當前有多少登錄用戶,但相對來說w命令會更好地顯示當前登錄用戶數的信息.

3.一般系統建議每個CPU內核的當前活動進程數量最好不要大於0.8,證明系統是空閑的,大於1且不小於3的時候,如果系統的其他資源很正常,那么系統的性能也可以接受的.但如果任務數大於5的話,那證明系統性能有問題了.以一個四核CPU的主機為例,當uptime的輸出結果超過15,那就意味着當前系統負載非常嚴重,需要分析當前的進程調度策略,是否有阻塞等,估計此時可能打開運行腳本都會非常緩慢的.

4.系統負載的3個值表示的是系統過去的1分鍾,5分鍾,15分鍾的一個平均值.通過這3個值的信息,我們 可以分析出系統負載的趨勢:是否增加,穩固,降低等.

Linux系統性能分析思路和實踐

負載uptime命令

CPU top命令

Windows 系統性能分析思路和實踐

性能監視器綜述:

perfmon 進入性能監視器

中間件Tomcat 監控 Probe

監控項

類別	計數器	描述
tomcat	JVM 內存	關注GC 回收頻率,Full GC 次數越少越好
	最大線程數	線程池連接數長期大80%以上,建議優化
	數據庫連接數	活動連接數長期大於80%以上,建議優化連接池
	請求數 請求狀態	線程數,線程狀態,大量 Blocked 狀態線程可以 Dump 線程棧信息進行分析

性能調優常用手段:

1.空間換時間,內存,緩存就是典型的空間換時間的例子.利用內存緩存從磁盤上取出的數據,CPU請求數據直接 從內存中獲取,從而獲取比從磁盤讀取數據更高的效率

2.時間換空間:當空間成為瓶頸時,切分數據分批次處理,用更少的空間完成任務處理.上傳大附件時經常用這種方式.

3.分而治之:把任務切分,分開執行,也方便並行執行來提高效率.

4.異步處理:業務鏈路上有任務時間消耗較長,可以拆分業務,減少阻塞影響.常見的異步處理機制有MQ(消息隊列),目前在互聯網應用中大量使用.

5.並行:用多個進程或者線程同時處理業務,縮短業務處理時間,比如我們在銀行辦理業務時,如果排隊人數較多時,銀行會加開櫃台.

6.離用戶更近一些:比如CDN技術,把用戶的靜態資源放在離用戶更近的地方.

7.一切可擴展:業務模塊化,服務化,良好的水平擴展能力.

分布式架構的運用給性能帶來了革命性的提升,業務流程的調整也會顯著提升系統性能,單系統的調優能夠壓榨出更高的處理能力.

系統的發展:

單體--à集群--à分布式--à分布式集群

單機性能分析與調優

客戶端--à應用服務器--à數據庫

我們的服務運行在中間件上,中間件與DB運行在操作系統上,操作系統來管理計算機硬件設備(CPU,內存,磁盤,網卡等設備).

單機性能分析流程:

Client:客戶端

Load Machine:負載生成器—模擬用戶負載

webserver:提供Web服務的服務器,即我們訪問的web頁面由此服務器提供服務;一般部署在Nginx,Apache等中間件上.

Middleware:中間件,比如Tomcat,Jboss,WebLogic等

OS:操作系統

System Resource:系統資源

APPserver:應用服務器,實現業務邏輯

DB:數據庫服務器

配置優化:

JVM配置優化

連接池:

連接池配置參數

連接池配置多少連接合適

監控連接池

線程池:

緩存機制: