引言
編寫目的
本測試報告，在效能測試結束階段，對測試結果進行分析，並給出結論。
術語定義
1、事務平均響應時間 (Average Transaciton Response Time)
“事務平均響應時間”顯示的是測試場景執行期間的每一秒內事務執行所用的平均時間，通過它可以分析測試場景執行期間應用系統的效能走向。
2、每秒通過事務數/TPS (Transactions per Second)
“每秒通過事務數/TPS”顯示在場景執行的每一秒鐘，每個事務通過、失敗以及停止的數量，使考查系統效能的一個重要引數。通過它可以確定系統在任何給定時刻的時間事務負載。分析TPS主要是看曲線的效能走向，將它與平均事務響應時間進行對比，可以分析事務數目對執行時間的影響。
3、併發使用者數 (Vuser)
“併發使用者數量”，在同一時刻與伺服器進行互動的線上使用者數量。這些使用者的最大特徵是和伺服器發生了互動。
預期讀者
本文件閱讀物件一般為專案經理、測試經理、研發經理，技術老鳥等。
測試目的
本報告是為了反映中介軟體各個場景下在多使用者併發訪問的情況下系統的表現情況.
本次測試從事務響應時間、併發使用者數、系統資源使用等多個方面，以專業的效能測試工具，分析出當前系統的效能表現，以實際測試資料與預期的效能要求比較，檢查系統是否達到既定的效能目標。
環境配置
伺服器：
|
描述 |
OS |
臺數 |
CPU |
Mem |
IP |
|
應用伺服器 |
Linux |
2 |
4核 |
4G |
10.126.3.59 10.126.3.61 |
|
Nginx |
Linux |
1 |
12核 |
6G |
10.126.3.63 |
|
Node伺服器 |
Linux |
1 |
4核 |
4G |
10.126.3.59:1337 |
|
壓力機 |
windows |
2 |
8核 |
4G |
10.126.3.58 10.126.3.62 |
應用配置：
|
配置物件 |
引數 |
配置 |
說明 |
|
Tomcat /context.xml |
sticky |
true |
粘性Session機制 |
|
lockingMode |
auto |
非粘性Session的鎖定策略 |
|
|
sessionBackupAsync |
false |
是否應該被非同步儲存到Memcached |
|
|
operationTimeout |
5000毫秒 |
||
|
sessionBackupTimeout |
5000毫秒 |
備份Session超時時間 |
|
|
Tomcat / server.xml |
maxThreads |
500 |
執行緒池最大執行緒數 |
|
minSpareThreads |
5 |
||
|
acceptCount |
1000 |
排隊長度 |
|
|
keepAliveTimeout |
20000 |
||
|
web.xml |
session-timeout |
30分 |
|
|
日誌級別 |
level value |
error |
判斷日誌記錄與否 |
|
JVM |
最小堆記憶體 |
2000M |
|
|
最大堆記憶體 |
2000M |
||
|
最大永久代MaxPermSize |
256m |
||
|
GC策略 |
預設 |
||
|
其他 |
-XX:-HeapDumpOnOutOfMemoryError |
LR配置(true表示選中，false表示不選中)：
|
配置物件 |
引數 |
配置 |
說明 |
|
ignore think time |
true |
忽略思考時間 |
|
|
download non-HTML resources |
true |
下載圖片 |
|
|
continue on error |
true |
錯誤時仍然繼續 |
|
|
run user as thread |
true |
執行使用執行緒方式 |
|
|
simulate a new user on each iteration |
true |
每次迭代清除http上下文 |
Tomcat
|
單個節點 |
||||
|
HTML |
||||
|
併發使用者數 |
10 |
20 |
50 |
100 |
|
每秒通過事務數TPS |
19305 |
32584 |
44195 |
40566 |
|
平均響應時間 |
0 |
0.001 |
0.001 |
0.002 |
|
JSP |
||||
|
併發使用者數 |
10 |
20 |
50 |
100 |
|
每秒通過事務數TPS |
19745 |
27982 |
33233 |
32576 |
|
平均響應時間 |
0 |
0.001 |
0.001 |
0.002 |
|
Serverlet |
||||
|
併發使用者數 |
10 |
20 |
50 |
100 |
|
每秒通過事務數TPS |
19305 |
28591 |
32460 |
34249 |
|
平均響應時間 |
0 |
0.001 |
0.001 |
0.002 |
問題及結果分析
隨著併發使用者數的增加，TPS值在隨之呈增長趨勢。
此應用沒有使用資料庫，應用和壓力機記憶體使用正常，資源使用正常，均不構成系統的瓶頸。
Nginx+Tomcat
結果資料
|
單個節點 |
||||
|
HTML |
||||
|
併發使用者數 |
10 |
20 |
50 |
100 |
|
每秒通過事務數TPS |
13252 |
21481 |
31044 |
34275 |
|
平均響應時間 |
0.001 |
0.002 |
0.004 |
0.008 |
|
JSP |
||||
|
併發使用者數 |
10 |
20 |
50 |
100 |
|
每秒通過事務數TPS |
12267 |
19230 |
25603 |
30903 |
|
平均響應時間 |
0.001 |
0.002 |
0.004 |
0.008 |
|
Serverlet |
||||
|
併發使用者數 |
10 |
20 |
50 |
100 |
|
每秒通過事務數TPS |
12007 |
19610 |
25135 |
29242 |
|
平均響應時間 |
0.001 |
0.002 |
0.004 |
0.008 |
|
兩個節點 |
||||
|
HTML |
||||
|
併發使用者數 |
10*2 |
20*2 |
50*2 |
100*2 |
|
每秒通過事務數TPS |
22160 |
33492 |
45619 |
41595 |
|
平均響應時間 |
0.001 |
0.002 |
0.004 |
0.008 |
|
JSP |
||||
|
併發使用者數 |
10*2 |
20*2 |
50*2 |
100*2 |
|
每秒通過事務數TPS |
20071 |
31514 |
39274 |
36363 |
|
平均響應時間 |
0.001 |
0.002 |
0.004 |
0.008 |
|
Serverlet |
||||
|
併發使用者數 |
10*2 |
20*2 |
50*2 |
100*2 |
|
每秒通過事務數TPS |
20050 |
32584 |
39195 |
40566 |
|
平均響應時間 |
0.001 |
0.002 |
0.004 |
0.008 |
問題及結果分析
從單節點來看，HTML,JSP, Serverlet結果走勢相近，增加Nginx後會存在一定的效能損耗，負載均衡增加一個Tomcat節點，與單節點進行比較，TPS結果Serverlet約為1.7倍的增長，HTML約為1.6倍的增長，JSP約為1.6倍的增長。導致相同場景Nginx+2個Tomcat的TPS比單個節點的Tomcat的TPS沒有2倍左右的增長的原因,系統的瓶頸是壓力機的磁碟IO過大，提升系統效能的方式，可以增加不在同一塊硬碟上的壓力機，減少在單個壓力機上的磁碟IO寫入情況而提高效能。應用程式沒有用到資料庫，應用伺服器的資源使用正常，均不構成系統的瓶頸。
Node
結果資料
|
單個節點 |
||||
|
Node 直接啟動 node server1.js +文字頁面 |
||||
|
併發使用者數 |
10 |
20 |
50 |
100 |
|
每秒通過事務數TPS |
13010 |
15317 |
14123 |
15373 |
|
平均響應時間 |
0 |
0.001 |
0.001 |
0.002 |
|
Node pm2啟動 1個節點 |
||||
|
併發使用者數 |
10 |
20 |
50 |
100 |
|
每秒通過事務數TPS |
13660 |
15097 |
15133 |
15540 |
|
平均響應時間 |
0 |
0.001 |
0.001 |
0.002 |
|
Node pm2啟動 4個節點 |
||||
|
併發使用者數 |
10 |
20 |
50 |
100 |
|
每秒通過事務數TPS |
17597 |
28405 |
38392 |
41549 |
|
平均響應時間 |
0 |
0.001 |
0.001 |
0.002 |
問題及結果分析
Node 直接啟動與pm2啟動差異不大，Node啟動4個節點TPS高於單個節點2.7倍。
此應用沒有使用資料庫，應用和壓力機記憶體使用正常，資源使用正常，均不構成系統的瓶頸。
Node+Tomcat
結果資料
|
單個節點 |
||||
|
HTML |
||||
|
併發使用者數 |
10 |
20 |
50 |
100 |
|
每秒通過事務數TPS |
8480 |
11856 |
11437 |
11339 |
|
平均響應時間 |
0.001 |
0.002 |
0.004 |
0.008 |
|
JSP |
||||
|
併發使用者數 |
10 |
20 |
50 |
100 |
|
每秒通過事務數TPS |
8214 |
11264 |
11514 |
11269 |
|
平均響應時間 |
0.001 |
0.002 |
0.004 |
0.008 |
|
Serverlet |
||||
|
併發使用者數 |
10 |
20 |
50 |
100 |
|
每秒通過事務數TPS |
5422 |
7878 |
8926 |
9013 |
|
平均響應時間 |
0.001 |
0.002 |
0.004 |
0.008 |
問題及結果分析
從單節點來看，HTML,JSP, Serverlet結果走勢相近，
此應用沒有使用資料庫，應用和壓力機記憶體使用正常，資源使用正常，均不構成系統的瓶頸
Node+Nginx+ Tomcat
結果資料
|
單個節點 |
||||
|
HTML |
||||
|
併發使用者數 |
10 |
20 |
50 |
100 |
|
每秒通過事務數TPS |
7235 |
9563 |
9969 |
10254 |
|
平均響應時間 |
0.001 |
0.002 |
0.004 |
0.008 |
|
JSP |
||||
|
併發使用者數 |
10 |
20 |
50 |
100 |
|
每秒通過事務數TPS |
5736 |
8030 |
8384 |
9050 |
|
平均響應時間 |
0.001 |
0.002 |
0.004 |
0.008 |
|
Serverlet |
||||
|
併發使用者數 |
10 |
20 |
50 |
100 |
|
每秒通過事務數TPS |
6028 |
8570 |
9141 |
8763 |
|
平均響應時間 |
0.001 |
0.002 |
0.004 |
0.008 |
|
2個Tomcat節點 |
||||
|
HTML |
||||
|
併發使用者數 |
10*2 |
20*2 |
50*2 |
100*2 |
|
每秒通過事務數TPS |
9494 |
10988 |
11679 |
11280 |
|
平均響應時間 |
0.002 |
0.003 |
0.008 |
0.015 |
|
JSP |
||||
|
併發使用者數 |
10*2 |
20*2 |
50*2 |
100*2 |
|
每秒通過事務數TPS |
8995 |
9251 |
10134 |
10551 |
|
平均響應時間 |
0.002 |
0.003 |
0.008 |
0.015 |
|
Serverlet |
||||
|
併發使用者數 |
10*2 |
20*2 |
50*2 |
100*2 |
|
每秒通過事務數TPS |
9080 |
9741 |
10186 |
10208 |
|
平均響應時間 |
0.002 |
0.003 |
0.007 |
0.015 |
問題及結果分析
從單節點來看，HTML,JSP, Serverlet結果走勢相近，增加Nginx，Node後會存在一定的效能損耗，負載均衡增加一個Tomcat節點，TPS沒有呈2倍增長。系統的瓶頸是壓力機的磁碟IO過大，提升系統效能的方式，可以增加壓力機的方式，增加不在同一塊硬碟上的壓力機，減少在單個壓力機上的磁碟IO寫入情況而提高效能。
縱向比較資料
測試結論
隨著系統架構的變化TPS逐層下降，每增加一層Nginx或者Node都存在一定的效能損耗, 系統的瓶頸是壓力機的磁碟IO過大，提升系統效能的方式，可以增加不在同一塊硬碟上的壓力機，減少在單個壓力機上的磁碟IO寫入情況而提高效能。
此次中介軟體架構測試為今後其他專案測試提供參考資料比對
TIPS
文章開源我的部落格：地址（轉載請說明出去）
個人最新全棧架構體系：Creek-dam-nova (歡迎大家star)