GUI界面中的plugins manager中的jpgc-Standard set，其中共包含以下的文件：
jpgc-dummy
jpgc-fifo
jpgc-graphs-basic
jpgc-perfmon
jpgc-tst
jpgc-sense
jpgc-functions
jpgc-casutg
jpgc-ffw
界面
線程組
jp@gc - Stepping Thread Group，如下圖
建立壓力模型，持續加壓
This Group will start 100 threads：這次的測試總共會起100個線程。
First , wait for 10 seconds：等待10s后開始起線程，也就是不等待直接起線程。
Then start 1 threads ：最開始啟動1個線程
Next add：10 threads every：10 using ramp-up：5 每10秒在5秒內啟動10個線程
Then hold load for 12 seconds. ：全部的線程起來后，運行12s 后開始停止（跟loadrunner類似，從jmeter聚合報告里面可以看出來，這里的hold load 的意思，其實是這些線程，一直在請求，相當於jmeter普通線程組里面的循環運行）。
Finally , stop 5 threads every 10 seconds：每隔10秒停止5個線程
jp@gc - Ultimate Thread Group，如下圖
跟上面那個線程組有些類似，不過這個是幾個設置的結合，像這里有設置兩個線程組（1、不延遲，20s內起100個線程，hold 60s后，10s內停止；），執行的時候，這兩個線程組是同時按照自己的規則開始執行的，每一時刻，得到的結果都是兩個線程組的疊加。
監控器
jp@gc - Active Threads Over Time
不同時間活動用戶數量展示（圖表）
jp@gc - Flexible File Writer
這個插件允許你靈活記錄測試結果
Filename：結果記錄的地方
Overwirte existing file：是否覆蓋這個文件
Ｗrite File Header：文件的頭(即文件的第一行)
Record each sample：記錄不同的sample（記錄哪些內容，什么順序，如何隔開不同的值）
Write File Footer：文件的結尾（即文件的最后一行）
jp@gc - PerfMon Metrics Collector
服務器性能監測控件，包括CPU，Memory，Network，Ｉ/Ｏ等等（此功能用到在需監聽的服務器上啟動startAgent）
Add Row 可以添加需要監控的服務器ip，端口號默認為4444，監控內容CPU/MEMORY/DISKS I/O等
jp@gc - Response Times Over Time
響應時間超時，顯示每個采樣以毫秒為單位的平均響應時間
展示響應時間曲線
jp@gc - Transactions per Second
每秒事務數，服務器每秒處理的事務數
用於展示TPS曲線
ServerAgent
下載解壓ServerAgent-2.2.1.zip文件，將解壓后的文件夾放在需要監控的服務器端，Linux和windows通用，只需啟動服務即可
默認端口是4444，如果占用需要修改
windows平台運行ServerAgent.jar文件
linux服務器上首先將startAgent.sh設定為可執行文件：
chmod 777 startAgent.sh
./startAgent.sh執行文件
如果要將該文件設置為后台執行不關閉
Nohup ./startAgent.sh &
在服務器上開啟startAgent服務后，再在jmeter上運行腳本，可以在jp@gc - PerfMon Metrics Collector上查看監控的圖形結果
性能測試中服務器關鍵性能指標
- 業務指標：如吞吐量(QPS、TPS)、響應時間(RT)、並發數、業務成功率等
- 資源指標：如CPU、內存、Disk I/O、Network I/O等資源的消耗情況
一. CPU
關於CPU資源，有三個重要概念：使用率、運行隊列和上下文切換，這里借助一張描述進程狀態的圖來進行簡要說明：
- Running：正在運行的進程
- Waiting：已准備就緒，等待運行的進程
- Blocked：因為等待某些事件完成而阻塞的進程，通常是在等待I/O，如Disk I/O，Network I/O等。
這里的Running和Waiting共同構成Linux進程狀態中的可運行狀態(task_running)，而Blocked狀態可以對應Linux進程狀態中的不可中斷睡眠狀態(task_uninterruptible)
在Linux可以使用vmstat來獲取這些數據：
[hbase@ecs-097 ~]$ vmstat 1 procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 6 0 0 4591436 176804 1185380 0 0 0 0 7915 10357 83 5 12 0 0
CPU使用率(CPU Utilization Percentages)：有進程處於Running狀態的時間/總時間。在vmstat主要通過us、sy和id三列數據來體現：
- us：用戶占用CPU的百分比
- sy：系統(內核和中斷)占用CPU的百分比
- id：CPU空閑的百分比
性能測試指標中，CPU使用率通常用us + sy來計算，其可接受上限通常在70%~80%。另外需要注意的是，在測試過程中，如果sy的值長期大於25%，應該關注in(系統中斷)和cs(上下文切換)的數值，並根據被測應用的實現邏輯來分析是否合理。
運行隊列進程數(Processes on run queue)：Running狀態 + Waiting狀態的進程數，展示了正在運行和等待CPU資源的任務數，可以看作CPU的工作清單，是判斷CPU資源是否成為瓶頸的重要依據。vmstat通過r的值來體現：
- r： 可運行進程數，包括正在運行(Running)和已就緒等待運行(Waiting)的。
如果r的值等於系統CPU總核數，則說明CPU已經滿負荷。在負載測試中，其可接受上限通常不超過CPU核數的2倍。
上下文切換(Context Switches)：簡單來說，context指CPU寄存器和程序計數器在某時間點的內容，(進程)上下文切換即kernel掛起一個進程並將該進程此時的狀態存儲到內存，然后從內存中恢復下一個要執行的進程原來的狀態到寄存器，從其上次暫停的執行代碼開始繼續執行至頻繁的上下文切換將導致sy值增長。vmstat通過cs的值來體現：
- cs：每秒上下文切換次數。
另外還有一個指標用來作為系統在一段時間內的負載情況的參考：
平均負載Load Average：在UNIX系統中，Load是對系統工作量的度量。Load取值有兩種情況，多數UNIX系統取運行隊列的值(vmstat輸出的r)，而Linux系統取運行隊列的值 + 處於task_uninterruptible狀態的進程數(vmstat輸出的b)，所以會出現CPU使用率不高但Load值很高的情況。Load Average就是在一段時間內的平均負載，系統工具top、uptime等提供1分鍾、5分鍾和15分鍾的平均負載值。
[hbase@ecs-097 ~]$ top top - 19:23:28 up 18:05, 3 users, load average: 0.80, 0.60, 0.53
上面示例中的0.80即是1分鍾內的Load average，以此類推。
當我們需要了解當前系統負載情況時，可以先查看Load average的值，如果系統持續處於高負載(如15分鍾平均負載大於CPU總核數的兩倍)，則查看vmstat的r值和b值來確認是CPU負荷重還是等待I/O的進程太多。
二. Memory
Memory資源也有三方面需要關注：可用內存，swap占用，頁面交換(Paging)，仍然借助一張圖來說明：
這里講到的內存，包括物理內存和虛擬內存，如上圖所示，物理內存和硬盤上的一塊空間(SWAP)組合起來作為虛擬內存(Virtual Memory)為進程的運行提供一個連續的內存空間，這樣的好處是進程可用的內存變大了，但需要注意的是，SWAP的讀寫速度遠低於物理內存，並且物理內存和swap之間的數據交換會增加系統負擔。虛擬內存被分成頁(x86系統默認頁大小為4k)，內核讀寫虛擬內存以頁為單位，當物理內存空間不足時，內存調度會將物理內存上不常使用的內存頁數據存儲到磁盤的SWAP空間，物理內存與swap空間之間的數據交換過程稱為頁面交換(Paging)。
可用內存(free memory)：內存占用的直觀數據，vmstat輸出free的值，可用內存過小將影響整個系統的運行效率，對於穩定運行的系統，free可接受的范圍通常應該大於物理內存的20%，即內存占用應該小於物理內存的80%。在壓力測試時，系統內存資源的情況應該用可用內存結合頁面交換情況來判斷，如果可以內存很少，但頁面交換也很少，此時可以認為內存資源還對系統性能構成嚴重影響。
頁面交換(Paging)：頁面交換包括從SWAP交換到內存和從內存交換到SWAP，如果系統出現頻繁的頁面交換，需要引起注意。可以從vmstat的si和so獲取：
- si：每秒從SWAP讀取到內存的數據大小
- so：每秒從內存寫入到SWAP的數據大小
SWAP空間占用:可以從vmstat的swpd來獲取當前SWAP空間的使用情況，應該和頁面交換結合來分析，比如當swpd不為0，但si，so持續保持為0時，內存資源並沒有成為系統的瓶頸。
三. Disk
磁盤通常是系統中最慢的一環，一是其自身速度慢，即使是SSD，其讀寫速度與內存都還存在數量級的差距，二是其離CPU最遠。另外需要說明的是磁盤IO分為隨機IO和順序IO兩種類型，在性能測試中應該先了解被測系統是偏向哪種類型。
-
隨機IO：隨機讀寫數據，讀寫請求多，每次讀寫的數據量較小，其IO速度更依賴於磁盤每秒能IO次數(IOPS)。
-
順序IO：順序請求大量數據，讀寫請求個數相對較少，每次讀寫的數據量較大，順序IO更重視每次IO的數據吞吐量。
對於磁盤，首要關注使用率，IOPS和數據吞吐量，在Linux服務區，可以使用iostat來獲取這些數據。
[hbase@ecs-097 ~]$ iostat -dxk 1 Linux 2.6.32-504.3.3.el6.x86_64 (ecs-097) 08/01/2016 _x86_64_ (4 CPU) avg-cpu: %user %nice %system %iowait %steal %idle 0.52 0.00 0.13 0.06 0.00 99.28 Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util xvda 0.10 6.63 0.40 2.57 6.22 36.80 29.00 0.04 14.63 1.19 0.35
(設備)使用率：統計過程中處理I/O請求的時間與統計時間的百分比，即iostat輸出中的%util，如果該值大於60%，很可能降低系統的性能表現。
IOPS：每秒處理讀/寫請求的數量，即iostat輸出中的r/s和w/s，個人PC的機械硬盤IOPS一般在100左右，而各種公有雲/私有雲的普通服務器，也只在百這個數量級。預先獲取到所用服務區的IOPS能力，然后在性能測試中監控試試的IOPS數據，來衡量當前的磁盤是否能滿足系統的IO需求。
數據吞吐量：每秒讀/寫的數據大小，即iostat輸出中的rkB/s和wkB/s，通常磁盤的數據吞吐量與IO類型有直接關系，順序IO的吞吐能力明顯優與隨機讀寫，可以預先測得磁盤在隨機IO和順序IO下的吞吐量，以便於測試時監控到的數據進行比較衡量。
四. Network
網絡本身是系統中一個非常復雜的部分，但常規的服務端性能測試通常放在一個局域網進行，因為我們首先關注被測系統自身的性能表現，並且需要保證能在較少的成本下發起足夠大的壓力。因此對於多數系統的性能測試，我們主要關注網絡吞吐量即可，對於穩定運行的系統，需要為被測場景外的業務流出足夠的帶寬；在壓力測試過程中，需要注意瓶頸可能來自於帶寬。
在Linuxf服務器，可以使用iptraf來查看本機網絡吞吐量，如：
[root@ecs-097 ~]# iptraf -d eth0 x Total rates: 67.8 kbits/sec Broadcast packets: 0x x 54.2 packets/sec Broadcast bytes: 0 x x x x Incoming rates: 19.2 kbits/sec x x 25.4 packets/sec x x IP checksum errors: 0 x x Outgoing rates: 48.7 kbits/sec x x 28.8 packets/sec
五. 總結
性能測試中，數據收集很重要，但是更重要的是快速抓住關鍵數據，讀懂數據的含義。
本文主要介紹服務端性能測試中，對於CPU、內存等各種系統資源，通常首要關注的數據，以及這些數據在Linux服務器上的獲取方式。
在實際測試中，通常會持續收集這些數據，如使用nmon，JMeter的PerfMon插件，以及zabbix等專門的系統監控工具
參考資料
Load (computing)
Process state
Linux Performance Analysis in 60,000 Milliseconds