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配置優化

連接配接池:

連接配接池配置參數

連接配接池配置多少連接配接合适

監控連接配接池

線程池:

緩存機制: