本文主要是介绍基于Jmeter的web系统后端接口压测报告,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
文章目录
- 一、测试目的
- 二、测试内容
- 三、测试环境
- 四、测试方法
- 4.1、压测工具和指标
- 4.2、测试时间
- 五、统计指标
- 六、测试结果
- 6.1、第一轮压测
- 6.1.1、聚合报告
- 6.1.2、接口压测实况图(90并发)
- 6.1.3、第一轮压测分析
- 6.2、第二轮压测
- 6.2.1、聚合报告
- 6.2.2、接口压测实况图(90并发)
- 6.2.3、第二轮压测分析
- 6.3、第三轮压测
- 6.3.1、聚合报告
- 6.3.2、接口压测实况图(30并发)
- 6.3.3、第三轮压测分析
- 七、结论
一、测试目的
针对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下专门压测,并使用命令行方式直接导出报告的方式节省工作量
这篇关于基于Jmeter的web系统后端接口压测报告的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!