一場爲企業服務開發的性能測試報告

引言

編寫目的

本測試報告，在性能測試結束階段，對測試結果進行分析，並給出結論。

術語定義

一、事務平均響應時間 (Average Transaciton Response Time)

「事務平均響應時間」顯示的是測試場景運行期間的每一秒內事務執行所用的平均時間，經過它能夠分析測試場景運行期間應用系統的性能走向。

二、每秒經過事務數/TPS (Transactions per Second)

「每秒經過事務數/TPS」顯示在場景運行的每一秒鐘，每一個事務經過、失敗以及中止的數量，使考查系統性能的一個重要參數。經過它能夠肯定系統在任何給定時刻的時間事務負載。分析TPS主要是看曲線的性能走向，將它與平均事務響應時間進行對比，能夠分析事務數目對執行時間的影響。

三、併發用戶數 (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)