性能測試報告模版
芯盾時代-xxx項目
x.x.x系統
性能測試報告
北京芯盾時代科技有限公司
201x年xx月xx
修訂記錄
|
版本號 |
修訂人 |
修訂日期 |
修訂描述 |
|
V0.1 |
芯盾 |
201x/xx/xx |
初次創建 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
一. 測試概要... 3
1.1 測試目的... 3
1.2 名詞解釋... 3
二. 測試環境... 4
2.1 測試硬件環境... 4
2.1.1 硬件查詢命令... 4
2.1.2 硬件信息列表... 4
2.2 環境軟件列表... 5
2.2.1 軟件查詢命令... 5
2.2.2 軟件信息列表... 5
2.3 測試地址信息... 5
三. 測試準備... 6
3.1 施壓方案... 6
3.1.1 初始VU確定... 6
3.1.2 測試場景選擇... 6
3.1.3 數據選取... 6
3.1.4 測試腳本... 6
3.2 監控方案... 6
3.2.1 Nmon監控... 6
3.2.2 JVM監控... 7
3.3 調優方案... 7
3.3.1 系統資源限制優化... 7
3.3.2 Tomcat線程配置... 8
3.3.3 Tomcat內存配置... 9
3.3.4 Nginx配置... 9
3.3.5 Oracle連接數配置... 9
3.4 測試計劃... 10
四. 測試過程... 11
4.1 測試標準... 11
4.2 基準測試... 11
4.2.1 測試目的... 11
4.2.2 運行結果... 11
4.3 負載測試... 12
4.3.1 測試目的... 12
4.3.2 運行結果... 12
4.4 並發測試... 13
4.4.1 測試目的... 13
4.4.2 運行結果... 13
4.5 穩定性測試... 13
4.5.1 測試目的... 13
4.5.2 運行結果... 14
五. 性能分析... 15
六. 測試結論... 16
一. 測試概要
1.1 測試目的
l 考察系統在測試環境下，單臺應用服務器下的系統處理能力。
l 對測試階段中性能測試的各項工作進行總結評價。
1.2 名詞解釋
l 事務：是指客戶端通過接口發送請求後，服務器成功接收並返回到客戶端的過程。
l TPS：是transaction per second的縮寫，代表每秒執行的事務數量，可基於測試周期內完成的事務數量計算得出。例如，用戶每分鐘執行6個事務，TPS為6 / 60s = 0.10 TPS。
l 事務平均響應時間：是指多個事務的響應時間的平均值。
l VU：是Virtual user的縮寫，指的是虛擬用戶，用於模擬並發使用。
l 並發：服務器在瞬間可以承受的最大用戶數。計算方法：TPS*接口超時時間（一般不超過3秒）。
l ART：是average response time的縮寫，表示平均響應時間。
l 負載測試：通過不斷的增加線程，逐步增加系統的壓力，在服務器的性能指標不出現異常（CPU占用不超過80%，不存在swap空間波動），得出最有的TPS和響應時間。
l 並發測試：驗證系統的並發處理能力。一般是和服務器端建立大量的並發連接，通過客戶端的響應時間和服務器端的性能監測情況來判斷系統是否達到了既定的並發能力指標。
l 穩定性測試：系統在負載一段時間後，是否依然穩定運行，重點關註內存泄漏，服務器資源占用，線程數變化，事務的成功率。
二. 測試環境
2.1 測試硬件環境
2.1.1 硬件查詢命令
l IP地址：ifconfig
l 主機名：hostname
l CPU配置：cat /proc/cpuinfo | grep name | cut -f2 -d: | uniq –c
l 內存配置：free –g
l 外網通過以下命令檢測：wget https://raw.githubusercontent.com/sivel/speedtest-cli/master/speedtest.py，chmod a+rx speedtest.py，mv speedtest.py /usr/local/bin/speedtest，Chown root:root /usr/local/bin/speedtest，speedtest。
l 測試內網上行下行網速，iperf3，目前測試環境197 198 199 209 已安裝好命令，例如：測試197 到 209 的網速，在209執行iperf3 -s -p 12345，在197執行iperf3 -c 192.168.1.209 -p 12345。
l 磁盤配置：df –h
l 測試磁盤寫入速度：dd bs=128k count=10k if=/dev/zero of=test conv=fdatasync
2.1.2 硬件信息列表
l 本次測試采用docker部署，在宿主機197（40核128G）上模擬3臺主流機型8核16G。
|
序號 |
容器名稱 |
端口 |
用途 |
CPU配置 |
內存配置 |
網絡配置 |
磁盤配置 |
備註 |
|
1 |
dfs_pre_17_redis |
6379 |
Redis |
8 |
16G |
千兆 |
5T |
|
|
2 |
dfs_pre_17_es |
9200/9300 |
ES |
|
||||
|
3 |
dfs_pre_17_tomcat |
8080à8111 10001->10001 |
Tomcat |
|
||||
|
4 |
宿主機192.168.1.198 |
NULL |
壓測 |
40 |
128G |
千兆 |
5T |
|
2.2 環境軟件列表
2.2.1 軟件查詢命令
分別通過如下命令查看對應軟件的版本號：
l Tomcat:./tomct/bin/version.sh
l JDK:java –verison
l Redis:redis/src/redis-server
l Nginx:./nginx/sbin/nginx –v
l Oracle: select * from v$version;
l Jmeter:jmeter –v
2.2.2 軟件信息列表
l 在docker采用compose方式編排，以下軟件安裝再docker容器中。
|
場景 |
軟件名稱 |
用途 |
版本 |
備註 |
|
1 |
Tomcat |
中間件 |
7.0.82 |
|
|
2 |
JDK |
Java環境 |
1.7.0_79 |
|
|
3 |
Redis |
內存數據庫 |
3.2.8 |
|
|
4 |
Jmeter |
性能測試工具 |
3.2 |
|
|
5 |
Nmon |
監控工具 |
無 |
|
|
6 |
Docker |
虛擬化工具 |
18.09 |
|
2.3 測試地址信息
l 測試地址端口固定在compose文件中，以下均為宿主機端口。
|
場景 |
名稱 |
數值 |
備註 |
|
1 |
移動端接口 |
http://192.168.1.197:8111/xdid/mapi |
|
|
2 |
Web接口 |
http://192.168.1.197:8111/xdid/bapi |
|
|
3 |
Jvm監控 |
192.168.1.197:10001 |
|
三. 測試準備
3.1 施壓方案
3.1.1 初始VU確定
l 初始使用多少VU施壓一般可以根據服務器的邏輯cpu數量判斷。
l 查看服務器的邏輯cpu數量：cat /proc/cpuinfo | grep name | cut -f2 -d: | uniq –c。
l 根據實際測試經驗，一般取邏輯cpu的數量，作為初始VU數，階梯施壓。
3.1.2 測試場景選擇
l 性能測試業務場景選取，根據實際的業務情況選擇，三種設備指紋按照5:3:2比例進行。
l 性能測試場景依次選取為：基準測試，負載測試，並發測試，穩定性測試。
3.1.3 數據選取
l 數據按照每次請求均使用新數據方式。
l Android數據每條約16K左右，ios數據每條1K左右，web數據每條2K左右。
3.1.4 測試腳本
l 測試腳本執行：jmeter -n -t xxx.jmx -l xxx.jtl -e -o ./res
l 測試腳本jmx文件原文如下，附件形式：
l 測試腳本依賴的jar文件，需要到到jmeter 的lib/ext下面：
3.2 監控方案
3.2.1 Nmon監控
l Nmon監控服務器系統資源，ftp://192.168.1.99/incoming/2018-07-18-jsbank/nmon.tar.gz，解壓文件，sh begin,sh即可生成監控文件，文件在./result文件夾下，下載到本地用nmon_analyser.xls打開nmon文件。Begin.sh說明：./start-nmon -s 60 -c 61 -f -m result。-s 多久采集一次（單位：秒），-c采集次數。
3.2.2 JVM監控
l 監控tomcat所在服務器的JVM情況，vim tomcat/bin/catalina.sh 增加如下內容：
|
# add by huangs start JAVA_OPTS="$JAVA_OPTS -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=10001 -Dcom.sun.management.jmxremote.rmi.port=10001 -Dcom.sun.management.jmxremote.local.only=false -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Djava.rmi.server.hostname=192.168.1.197" # add by huangs end |
l 註意：需要容器跟宿主機端口一樣，ip寫宿主機的，rmi.port需要有，local.only=false。
l 配置完成進入本地jdk/bin目錄找到，jconsole.exe點擊，輸入對應的IP及端口即可。
l 也可配置Jvisualvm，可以保存監控過的信息，配置方法類似，先輸入ip，在輸出端口即可。
3.3 調優方案
3.3.1 系統資源限制優化
l 系統中新創建的用戶默認的打開文件數，最大系統線程數默認是1024，如下：
|
[xindun@mtg209 ~]$ ulimit -a open files (-n) 1024 max user processes (-u) 1024 |
l 如果出現不斷增加vu後，tps不增加，系統資源也沒增加情況，可以參考修改此項。
l 具體的修改方法（centos），sudo vim /etc/security/limits.d/20-nproc.conf詳情如下：
|
vi /etc/security/limits.conf # add by huangs * soft noproc 65536 * hard noproc 65536 * soft nofile 65536 * hard nofile 65536 # add over vi /etc/security/limits.d/20-nproc.conf # add by huangs 4096-->65535 * soft nproc 65536 |
3.3.2 Tomcat線程配置
l Tomcat默認最大線程數是150，實際執行性能測試150無法滿足實際需求，修改參考如下：
l 修改tomcat conf目錄下的server.xml,具體如下：
|
<Executor name="tomcatThreadPool" namePrefix="catalina-exec-" maxThreads="1500" minSpareThreads="150" maxIdleTime="300000"/> <Connector executor="tomcatThreadPool" port="8580" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" maxProcessors="1500" minProcessors="250" acceptCount="1500" URIEncoding="UTF-8"/> |
l 參數說明，如下：
|
name：共享線程池的名字。這是Connector為了共享線程池要引用的名字，該名字必須唯一。默認值：None； namePrefix:在JVM上，每個運行線程都可以有一個name 字符串。這一屬性為線程池中每個線程的name字符串設置了一個前綴，Tomcat將把線程號追加到這一前綴的後面。默認值：tomcat-exec-； maxThreads：該線程池可以容納的最大線程數。默認值：200； maxIdleTime：在Tomcat關閉一個空閑線程之前，允許空閑線程持續的時間(以毫秒為單位)。只有當前活躍的線程數大於minSpareThread的值，才會關閉空閑線程。默認值：60000(一分鐘)。 minSpareThreads：Tomcat應該始終打開的最小不活躍線程數。默認值：25。 executor：表示使用該參數值對應的線程池； minProcessors：服務器啟動時創建的處理請求的線程數； maxProcessors：最大可以創建的處理請求的線程數； acceptCount：指定當所有可以使用的處理請求的線程數都被使用時，可以放到處理隊列中的請求數，超過這個數的請求將不予處理。 |
3.3.3 Tomcat內存配置
l 修改Tomcat的內存配置，打開$TOMCAT_HOME/bin/catalina.sh文件（Windows系統是catalina.bat文件），大楖在250行左右，在JAVA_OPTS參數上添加內存參數設置即可。完整的JVM參數設置如下所示：
|
JAVA_OPTS="$JAVA_OPTS -server -Xms2048m -Xmx2048m -XX:PermSize=128m -XX:MaxPermSize=256 -Djava.awt.headless=true" |
l -server參數：表示以服務模式啟動，啟動速度會稍微慢一點，但性能會高很多。不加這個參數，默認是以客戶端模式啟動。
3.3.4 Nginx配置
l nginx配置：vim /nginx/conf/nginx.conf
|
user xindun; worker_processes 6; error_log logs/error.log; error_log logs/error.log notice; error_log logs/error.log info;
pid logs/nginx.pid;
events { worker_connections 1024; } |
l er_processes 6，表示nginx用的核心數。
l worker_connections 1024;表示每個核心nginx可以開始的線程數。
3.3.5 Oracle連接數配置
l 當前的數據庫連接數：select count(*) from v$process ;
l 數據庫允許的最大連接數：select value from v$parameter where name = ‘processes‘;
l 修改最大連接數:-alter system set processes = 300 scope = spfile;
l 查看當前有哪些用戶正在使用數據:
|
select osuser, a.username, cpu_time / executions / 1000000 || ‘s‘, b.sql_text, machine from v$session a, v$sqlarea b where a.sql_address = b.address order by cpu_time / executions desc; |
3.4 測試計劃
l 按照測試實際執行過程，測試計劃如下：
|
序號 |
任務描述 |
開始時間 |
結束時間 |
測試工時（天） |
測試人員 |
備註 |
|
1 |
性能測試方案計劃編寫 |
|
|
|
|
|
|
2 |
測試腳本、工具準備 |
|
|
|
|
|
|
3 |
測試數據準備 |
|
|
|
|
|
|
4 |
測試環境準備 |
|
|
|
|
|
|
5 |
首輪性能測試 |
|
|
|
|
|
|
6 |
性能測試調優 |
|
|
|
|
|
|
7 |
基準測試、負載測試 |
|
|
|
|
|
|
8 |
並發測試、穩定性測試 |
|
|
|
|
|
|
9 |
性能測試結果整理 |
|
|
|
|
|
|
10 |
輸出性能測試報告 |
|
|
|
|
|
l 綜上所述，測試周期大約*周，大部分時間用與性能調優。
四. 測試過程
性能測試過程均為測試單節點，如果需要測試集群可以參照整個第四章內容自行添加。
4.1 測試標準
l 啟動標準：測試方案部分、測試計劃部分、測試腳本、測試環境準備完畢方可啟動。
l 完成標準：測試過程無異常，結果滿足基本預期結果，事務成功率100%。
l 終止情況：腳本無法運行、系統資源超負荷、事務成功率不足100%、環境宕機等，問題得到修復後可以繼續測試。
4.2 基準測試
4.2.1 測試目的
l 運行單用戶30分鐘，驗證腳本的正確性，驗證系統的穩定性，為後續測試做保障。
l 獲得最基礎的性能指標（TPS、ART），最為後續測試結果的基礎比對，若小於基準測試結果，需要提前檢查環境配置和腳本。
4.2.2 運行結果
l 依次執行android ios web基準測試並記錄結果到下面表格，需要監控系統資源，如果資源出現瓶頸測試終止。
|
場景 |
VU |
運行時間（分鐘） |
TPS（筆/秒） |
響應時間（毫秒） |
成功率（百分比） |
|
Android |
1 |
30 |
|
|
|
|
iOS |
|
|
|
||
|
WEB |
|
|
|
4.3 負載測試
4.3.1 測試目的
通過不斷增加vu，觀察tps與相應時間的走勢，在系統資源正常與成功率100%的情況下，選取TPS的最大值，ART的最小值。
4.3.2 運行結果
|
場景 |
類型 |
VU |
運行時間（分鐘） |
TPS（筆/秒） |
ART（毫秒） |
|
1 |
Android |
10 |
30 |
|
|
|
2 |
20 |
|
|
||
|
3 |
40 |
|
|
||
|
4 |
iOS |
10 |
|
|
|
|
5 |
20 |
|
|
||
|
6 |
40 |
|
|
||
|
7 |
Web |
10 |
|
|
|
|
8 |
20 |
|
|
||
|
9 |
40 |
|
|
l Jmeter運行結果：
l Cpu使用情況：
l 磁盤使用情況：
l 內存使用情況：
l 網絡使用情況：
4.4 並發測試
l 使用負載測試最有的tps作為並發測試的初始值，並發數成倍遞增。
4.4.1 測試目的
l 測試在不同vu的情況下，系統所能承受的最大並發數。
4.4.2 運行結果
|
場景 |
類型 |
VU |
成功率 |
TPS（筆/秒） |
ART（毫秒） |
|
1 |
Android |
500 |
|
|
|
|
2 |
1000 |
|
|
|
|
|
3 |
1500 |
|
|
|
|
|
4 |
iOS |
500 |
|
|
|
|
5 |
1000 |
|
|
|
|
|
6 |
1500 |
|
|
|
|
|
7 |
Web |
500 |
|
|
|
|
8 |
1000 |
|
|
|
|
|
9 |
1500 |
|
|
|
l Jmeter運行結果：
l Cpu使用情況：
l 磁盤使用情況：
l 內存使用情況：
l 網絡使用情況：
4.5 穩定性測試
4.5.1 測試目的
測試系統在穩定的tps 並發的條件下，持續運行12小時，觀察系統事務的成功率，服務器的資源情況。
4.5.2 運行結果
依次執行android ios web基準測試並記錄結果到下面表格，需要監控系統資源，如果資源出現瓶頸測試終止。
|
場景 |
VU |
運行時間（分鐘） |
TPS（筆/秒） |
響應時間（毫秒） |
|
Android |
50 |
12*60 |
|
|
|
iOS |
|
|
||
|
WEB |
|
|
五. 性能分析
六. 測試結論
l 根據測試過程分析，根據TPS與響應時間成正比例遞增原則同時取TPS最大值，響應時間最小值的原則，最優測試數據結果結論如下。
l 性能測試結論：
①、TPS最大值：7132.4筆/秒。
②、平均響應時間為：15毫秒。
③、最大並發數1500。
④、系統7*24小時穩定運行。
性能測試報告模版