1. 安装JMeter及使用
1.1下载JMeter
登录官方网站找到下载链接进行下载:https://jmeter.apache.org/download_jmeter.cgi
1.2配置环境变量
配置JMeter环境变量
新建变量名 JMETER_HOME
值为:JMeter解压目录\bin(下载的文件解压目录)
安装Java8+
参考文章:https://blog.csdn.net/weixin_45078706/article/details/115830318
2.新建.Net程序
选择Asp.Net Core Web API
输入项目名称
选择框架.Net5.0
在Controllers添加包含读/写的API控制器
这次分别测试上面4个接口在不同框架下的响应情况
生成解决方案,找到生成目录下的JmeterTest.exe直接运行
访问http://localhost:5000/swagger/index.html
因为框架默认引用了swagger组件,所以可以直接访问,但页面出现404
修改Startup.cs代码,注释如下行
在此生成运行出现swagger页面
3.Jmeter接口测试
打开下载Jmeter解压出来bin目录下的jmeter.bat
出现下面窗口(方便使用切换到中文版本,步骤:Options->Choose Language->Chinese(Simplified))
3.1新建一个线程组,线程就是模拟用户请求,可设置线程数来控制请求的数量
参数说明:
- 线程数:模拟请求的用户数量
- Ramp-Up时间(秒):达到启用指定线程数的时间
- 循环次数:线程执行循环的次数,一般在初次测试接口时设置为1,正式压测时设置的永远
- Same user on each iteration:待补充..
- 延迟创建线程知道需要:待补充..
- 调度器:持续时间(秒):程序持续运行时间,启动延时(秒):启动的线程延时多久执行下一组
3.2添加Http请求默认值
3.3添加HTTP信息头管理器
添加Content-Type:application/json
3.4添加Http请求
按照需要测试的几种请求接口,这里需要添加四个Http请求
3.5添加响应断言,对请求的接口进行断言,判断是否请求成功
3.6添加查看结果树,查看详细的接口请求及返回内容
3.7添加聚合报告查看整体接口请求聚合情况
3.8进行初步测试确保接口响应没有问题
3.9修改线程数,启用调度器,再次启动压测请求
第一次请求出现了大量的:already in use: connect
搜索找到解决方案修改注册表:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
在Parmeters右键新建DWORD值,命名为MaxUserPort,然后选择十进制并输入数据65534后保存
然后测试发现还是一样的错误,检查参数设置发现Same user on each iteration没有勾选,查询了下资料大概意思是如果选中表示每次请求是同一个用户,不勾选循环的每次是不同的用户
3.10net5.0请求300s结果如下,大概每秒59886.9次请求
3.11切换至.net6.0
再次进行测试
请求300s结果如下,大概每秒62232.7次请求,提升了2346,基于net5.0提升了3.9%
3.12切换至.net7.0
再次进行测试
请求300s结果如下,大概没秒63108次请求,基于net6.0提升876次,提升1.4%,基于net5.0提升3222次,提升5.3%
下面是使用命令行模式启用jmeter
jmeter -n -t C:\Users\Administrator\.Net框架性能测试.jmx -l F:\apache-jmeter-5.5\新建文件夹2\
result\
result.txt -e -o
F:\apache-jmeter-5.5\新建文件夹2\
result
说明:
C:\Users\Administrator\.Net框架性能测试.jmx
为测试计划文件路径
F:\apache-jmeter-5.5\新建文件夹2\
result\
result.txt
为测试结果文件路径
F:\apache-jmeter-5.5\新建文件夹2\
result
为web报告保存路径
3.13对比测试高性能Go语言测试
测试使用Go版本
测试结果,大概每秒90641次请求,单纯的接口响应性能相应上来说,对比.net有一定的优势(但是实际使用场景中还需要考虑数据处理,文件IO操作等情况),
总结
此次测试的结果都是基于本地电脑测试,测试结果可能无法反应实际的处理情况
本机电脑配置情况
写这篇文章的目的主要是想测试在特定的环境下,.net不同版本的响应能力,这样可以在开发新的项目时技术选型作为参考,此次测试要素太少,不能真正的反应一个框架的处理能力,应该需要从实际的业务去进行测试,比如从集合中查询一条数据,查询10条数据,包含分页,添加一条数据,更新一条数据,删除一条数据,这样的测试更符合实际的业务场景。
在这几天的评论中其实也学习到了一些,总结主要有下面几点
1.比如这次测试debug模式,是否考虑测试release模式,因为实际的正式部署环境使用的是release模式,但是这次测试debug,release两种模式结果差不多,我猜测的可能性是这两种在接口响应都一样优化到了极致,所以出现了大概一致的情况
2.jmeter使用方面,这次一开始使用的是图形模式,图形模式下本身jmeter会更占用部分系统性能,使用命令行模式会减少这部分性能的开销
3.有些地方更多的是依据经验测试,并没有考虑的全面,没有体现出足够的专业性
关于.net更专业的对比可以阅读链接文章 https://www.cnblogs.com/shanyou/p/16536009.html