基于Jmeter的web系统后端接口压测报告

---

一、测试目的

针对uat环境的用户并发量和系统瓶颈，都是未知的。
本轮压力测试，抽取部分代表性查询接口，主要是为了测试后台系统UAT环境主要接口吞吐量和响应时间，初步找出系统的瓶颈。

二、测试内容

压测接口清单

• api/nonmetalPla/list（pla(post)）
• api/warehouse/searchCarType （查询基础数据(post) ）
• api/dict/findDictByParentCode （根据父类编码查询下级字典(post) ）
• 压测数据库查询m_dict数据 （jdbc连接 ）

三、测试环境

环境	机器型号	CPU	操作系统	内存	磁盘
应用服务器	linux虚拟机	CPUIntel® Xeon® Gold 6132 CPU @ 2.60GHz 4个单核四线程	CentOS Linux release 7.5.1804 (Core) 单机	total：8G ，可用内存： free+buffers/cached = 2.3G	tatal：26G used：15G
压测机器	宏碁4750	单个双核四线程	win10 单机	8G	total:8G used:3G

四、测试方法

4.1、压测工具和指标

类别	说明
压测工具	apache-jmeter-5.1.1（单台win环境）
压测性能相关参数	协议: http 方法: get/post 并发数 、总请求数、吞吐率(TPS)、响应时间、错误率

4.2、测试时间

第一轮压测：
测试时间：9:00-12:00（工作时间） ，内网环境压测（VPN内网，非完全内网）
针对每个接口分别执行并发数10、30、90、270并发数执行120秒
第二轮压测：
测试时间：7:50-09:30（工作时间） ，内网环境压测（VPN内网，非完全内网）
针对每个接口分别执行并发数10、30、90、270并发数执行120秒
第三轮压测：
测试时间：09:00-09:30（工作时间） ，内网环境压测（VPN内网，非完全内网）
针对pla接口30并发数执行120秒

五、统计指标

进行压力测试，并对产生的每秒TPS，响应时间（min，ave，max）及错误率进行统计

六、测试结果

6.1、第一轮压测

时间：9:00-12:00（工作时间）

6.1.1、聚合报告

接口名称	数据量	并发数	持续时间	samples	average	min	max	median	90%Line	95%Line	99%Line	error%	tps(s)	received(kb/s)	sent(kb/s)
pla(post)	limit 10		120s
api/nonmetalPla/list		10		5113	233	73	2458	191	345	408	827	0	42.41921434	1672.45209	21.91383241
api/nonmetalPla/list		30		5323	673	146	8692	543	1196	1561	2619	0	43.96775313	1733.505954	22.71380996
api/nonmetalPla/list		90		6224	1737	161	26447	1262	3238	4445	8283	0	49.34982556	1945.703621	25.49419699
api/nonmetalPla/list		270		7586	4298	155	44290	3359	7611	9445	15606	0	59.22213375	2334.936724	30.59424683
查询基础数据(post)	limit 10
/api/warehouse/searchCarType		10		2602	459	113	3458	393	692	937	1496	0	21.5274388	1078.600366	11.28929163
/api/warehouse/searchCarType		30		4456	805	105	7980	670	1369	1712	2686	0	36.9694355	1852.298689	19.38729186
/api/warehouse/searchCarType		90		5044	2150	172	11822	1781	3441	4277	6622	0	41.092654	2058.886432	21.54956562
/api/warehouse/searchCarType		270		6504	5022	154	79084	3997	8100	10222	17749	0	51.1437356	2562.480956	26.82049416
根据父类编码查询下级字典(post)	limit 10
/api/dict/findDictByParentCode		10		652	1842	225	12681	1505	2617	5084	6542	0	5.201643464	3.682313378	2.722735251
/api/dict/findDictByParentCode		30		1942	1861	267	11447	1489	3467	4896	6968	0	15.58337346	10.10484372	8.156922043
/api/dict/findDictByParentCode		90		5464	1986	284	23215	1604	2840	5219	6941	0	43.72669217	28.97468862	22.88819043
/api/dict/findDictByParentCode		270		16931	1921	72	14632	1505	3356	5021	6597	1.07	131.6268411	88.65045632	68.13092412
jdbc连接	limit 10
压测数据库查询m_dict数据		10		17390	66	10	13343	40	116	179	312	0	145.2	145.46	0
压测数据库查询m_dict数据		30		18909	181	10	8165	118	351	474	845	0	157.5	157.78	0
压测数据库查询m_dict数据		90		15052	709	13	12010	538	1106	1566	6648	0.48	125.1	124.78	0
压测数据库查询m_dict数据		270		19391	1681	13	10848	1517	2593	3232	7707	0	158.1647635	158.47	0

6.1.2、接口压测实况图（90并发）

下面抽取并发量为90的情况下各个测试接口的资源情况，分别是内存和cpu状况图、响应时间、tps

一、api/nonmetalPla/list((post)）

二、/api/warehouse/searchCarType （查询基础数据(post) ）



三、/ api/dict/findDictByParentCode （根据父类编码查询下级字典(post) ）



四、压测数据库查询m_dict数据 （jdbc连接 ）

6.1.3、第一轮压测分析

• 带宽、内存、内存、磁盘等指标在网页查看一直表现的比较正常，在命令行直接进去服务器查看，cpu有超过100%的几次状况。
• 并发数在90以内时，接口响应时间基本能保证在2s内
• 普通数据库查询接口tps有提升空间，pla接口在10-270的并发下均能保持40tps以上
• warehouse查询(post) 接口相比pla接口仍较慢，可做进一步优化，考虑字段过多，sql查询方面的问题
• 根据父类编码查询下级字典(post)接口耗时非常严重，需要比较优先优化，考虑索引和sql方面的问题
• 数据库压测tps只有120-150左右，需要进一步提高，考虑服务器性能方面和mysql配置问题，在非工作时间有尝试压测
• 对于接口耗时较长的情况，目前引入了redis，但是目前用的地方很少，redis几乎闲置，接口可以考虑结合使用redis

一次压测数据不一定是准确的，有主要以下几点

• 服务器网络变化
• 服务器性能改变
• 压测主机网络变化
• DB数据量的变化
• 压测过程中部分请求 error / 超时影响

6.2、第二轮压测

压测时间：07:50-9:30（工作时间）

6.2.1、聚合报告

接口名称	数据量	并发数	持续时间		samples	average	min	max	median	90%Line	95%Line	99%Line	error%	tps(s)	received(kb/s)	sent(kb/s)
pla(post)	limit 10		120s
api/nonmetalPla/list		10		TOTAL	4038	296	95	9299	233	496	630	934	0	33.49841965	1330.286362	17.30533593
api/nonmetalPla/list		30		TOTAL	5134	698	76	7882	602	921	1107	3601	0	42.68835175	1695.236156	22.05286921
api/nonmetalPla/list		90		TOTAL	5830	1873	157	12518	1717	2293	3515	5551	0	47.52472019	1887.297604	24.55134471
api/nonmetalPla/list		270		TOTAL	5130	6483	459	26515	5727	10125	11911	16345	0	40.1323664	1593.733086	20.73244319
basedata(post)	limit 10
/api/warehouse/searchCarType		10		TOTAL	4272	451	94	17898	426	615	676	853	0.002340824	22.09544695	2040.372722	11.56003959
/api/warehouse/searchCarType		30		TOTAL	3028	1186	187	4492	1120	1586	1807	2567	0	25.12883924	2325.840943	13.17791667
/api/warehouse/searchCarType		90		TOTAL	2146	5096	264	37961	3563	10678	14950	24020	0	16.60528026	1536.928958	8.708042481
/api/warehouse/searchCarType		270		TOTAL	2916	11779	257	55320	10512	17029	20018	27637	0	21.09649694	1952.620886	11.06329966
根据父类编码查询下级字典(post)	limit 10
/api/dict/findDictByParentCode		10		TOTAL	31344	37	19	3256	28	37	56	245	0	261.1586499	392.5030881	136.7002308
/api/dict/findDictByParentCode		30		TOTAL	69339	51	21	7120	42	58	132	215	0	577.6083969	868.1048074	302.3418952
/api/dict/findDictByParentCode		90		TOTAL	87335	122	22	14538	94	219	274	500	0	727.2886254	1093.063666	380.6901398
/api/dict/findDictByParentCode		270		TOTAL	94655	339	22	6125	296	451	496	1331	0	786.713432	1182.374973	411.7953121
jdbc连接	limit 10
压测数据库查询m_dict数据		10		查询	43653	24	9	4549	18	30	44	139	0	363.6689299	364.3792208	0
压测数据库查询m_dict数据		30		查询	19069	187	20	22843	83	341	521	981	0	158.7694101	159.0795066	0
压测数据库查询m_dict数据		90		查询	31774	333	10	9448	231	576	805	1814	0	264.096682	264.6124958	0
压测数据库查询m_dict数据		270		查询	27057	1196	26	15632	902	2004	2398	4520	0	222.8252366	223.2604421	0

6.2.2、接口压测实况图（90并发）

下面抽取并发量为90的情况下各个测试接口的资源情况，分别是内存和cpu状况图、响应时间、tps


一、api/nonmetalPla/list((post)）



二、/api/warehouse/searchCarType （查询基础数据(post) ）



三、/ api/dict/findDictByParentCode （根据父类编码查询下级字典(post) ）



四、压测数据库查询m_dict数据 （jdbc连接 ）

6.2.3、第二轮压测分析

• 二轮压测发现pla接口和warehouse接口都是比较相近的tps结果数据，
• 数据字典接口翻了将近10倍，其数据也是不多的，但是结果差别如此的大。
• 压测数据库查询tps也翻了一倍，
  根据以上几个现象，首先能确定的是虽然内网环境，但是走vpn的情况下，网络存在不稳定，当前数据库仅该后台系统在使用，说明数据传输的耗时主要受网络方面的影响大。
  结合第一轮压测出现的一些问题，两轮下来，需要第三轮的测试，
  第三轮主要是判断数据量大小的网络传输，是否明细影响压测结果

6.3、第三轮压测

6.3.1、聚合报告

接口名称	数据量	并发数	持续时间	samples	average	min	max	median	90%Line	95%Line	99%Line	error%	tps(s)	received(kb/s)	sent(kb/s)
pla(post)
api/nonmetalPla/list	10	30	120s	5207	689	74	5609	608	1054	1356	2167	0	43.3	1717.91	22.35
api/nonmetalPla/list	1	30	120s	17408	205	48	5707	113	317	472	2120	0	144.8	629.9	74.65
api/nonmetalPla/list	0	30	120s	47035	75	24	21001	52	120	187	321	0	391.8	171.41	208.88

6.3.2、接口压测实况图（30并发）

下面抽取并发量为30压测的情况下各个测试接口的资源情况，分别是内存和cpu状况图、响应时间、tps
压测接口：api/nonmetalPla/list((post)
并发量：30

一、查询0条




二、查询1条



三、查询10条

6.3.3、第三轮压测分析

• 数据量大小的网络传输影响非常大
• 数据量越小传输越快，当前VPN的内网受VPN或内网网速影响较大
• 接口的数据量有必要缩减，会有明细的tps提升

七、结论

结合压测一、二、三分析，得到以下一些结论和建议：

• 主要问题在网络环境，网络的提升对压测tps的影响非常大。

• 工作时间的早上刚上班期间，服务器和带宽都是比较宽裕的状况，这几个目标接口的压测结果tps都提高了很多，vpn连接的内网压测对数据的准确性仍然有一定的影响

• 在网络正常的情况下，接口tps仍然只能在50左右。

• 服务器性能不是非常稳定，虚拟linux多个地方共用主机导致有波动，也影响接口性能，单独部署到一台服务器会事比较好的选择

• 数据库压测tps120-150，200+均出现，从二轮压测可以看出，除了网络之外，数据库tps仍可以继续提高，本地机器能达到1000tps，可以向着这个目标接近。

• 所有接口不需要的字段尽量缩减不返回到前端，可做进一步优化，考虑字段过多，sql查询方面的问题

• 对于接口耗时较长的情况，目前引入了redis，但是目前用的地方很少，redis几乎闲置，接口可以考虑结合使用redis

• 考虑下一轮的压测中直接在机房另一台linux/win下专门压测，并使用命令行方式直接导出报告的方式节省工作量