做性能测试,先是根据策略编写脚本,然后才是执行脚本,现在我已经编写好了脚本,一个最简单的脚本。
然后保存,运行,在察看结果树里,可以看到正确的响应结果。
现在,启一个线程让这个脚本一直循环运行,查看运行情况,因为是循环运行,HTTP请求,会执行很多次,而这些结果都在察看结果树里显示出来,就不是很好,所以在察看结果里里勾上,只显示错误的请求信息。
然后线程组配置成永远循环,调度器设置成60秒,我这里只是演示,就不去跑10分钟了。
配置好保存,清除之前的结果,之后就开始运行。
右上角,小框框里面显示的是脚本的运行时间,小三角形前面的数字,代表jmeter运行过程中的异常数,这个异常数和脚本里的错误是两码事。比如连接不上服务器,这里就会有异常。小圈圈前的0/1代表当前正在运行的线程数和脚本运行中的最大线程数,因为现在脚本已经停止运行了,所以没有线程在运行,所以前面就是0。而且我的脚本运行时,只启了一个线程,所以最大线程数就是1。在察看结果树里,没有结果输出,代表没有错误的请求,重点看聚合报告。
Label:是请求的名称。
#Samples:在脚本运行过程中,一共发了多少个请求。
Average:平均响应时间,服务器处理一个请求需要多少时间的平均值,单位:毫秒。
Median:响应时间的中间值,就是所有请求的响应时间从小到大排个序,正中间的那个值是多少。
90%Line:响应时间从小到大排序,在第90%位置处的值是多少,比如一共发了10000个请求,那么就是第9000个的值。
95%Line、99%Line同上。
Min:最小响应时间,就是所有请求中响应时间最短的那一个。
Max:最大响应时间,就是所有请求中响应时间最长的那一个。
Error %:错误率,错误请求占所有请求的比率是多少。
Throughput:这个就是常说的TPS了,也就是中文常说的吞吐量。代表的是服务处理请求的能力,服务器在1秒之内能处理多少个请求。
最后面两个就是每秒接收数据量和发送数据量,不过这两个值,有些情况下会没有。
因为跑的时间比较短,再跑长点时间,TPS可以到1000。因为我这个框架,业务比较简单,而且数据库里的数据也非常少,所以响应非常快。通过响应时间,我们可以推算出服务器一个线程,在1秒内可以处理多少个请求。比如这里是1毫秒,那么服务器一个线程,1秒是可以处理1000个请求的。不过呢,这个1毫秒是向下取整得来的,显示是1毫秒,而实际上可能是1.2或是1.3毫秒。再通过TPS,就可以推出服务器大致启了多少个线程在处理请求。比如平均响应时间是20毫秒,那么服务器一个线程一秒可以处理50个请求,如果TPS是400,那么就可以推出服务器大概是启了8个线程在处理请求。当然,这个并不是绝对的,尤其是在服务器没有达到极限的时候。接下来,再看服务器的资源使用情况。
可以看到,在刚开始发请求的时候,服务器的CPU使用率非常地高,最高的时候达到了75%,因为这个时候,服务器要创建很多线程,线程又要处理业务,所以CPU的使用率就变得很高了。然后,到了后期,线程都创建好了,那么就只有处理业务的消耗,所以CPU的使用率就慢慢的降下来了,并趋于平稳。内存就没有什么可看的了,跑得时间短,如果跑的时间比较长,比如10分钟,而在跑的过程中,一直在增高,那么就要考虑有内存泄露的问题了。而磁盘I/O,因为没有打日志,所以就完全没有了。
1个线程的跑完了,服务器的性能就有了一个基准值。那么就要再加线程跑,现在加到2个线程跑。
清除之前的结果,运行。
可以看到2个线程的时候,TPS是1677,相较于1个线程的TPS,没有达到2倍,存在着衰减,当然跑的时间太短,对比的数据,参考性不是很准确。然后,再启3个线程跑:
2个线程TPS是1677,3个线程是1729,只增加了一点点。那么就可以得出结论,服务器的TPS极限就是1700多一点。后面,再增加线程来压,TPS也增长不动,甚至还会出现下降的情况。
现在只是测试了一种情况,还有带参数的情况,只是脚本改一下,测试的过程是差不多的。再然后就是做参数化,让脚本在运行的过程中,不停地改变参数,来查看服务器的的性能,新建一个记事本,内容如下:
然后,在脚本里引入这个文件,读取里面的内容做参数。
然后线程组,设置启一个线程,循环4次,察看结果树的只显示错误,不勾选,运行一下,看结果。
可以看到,4次,每次运行的结果都不一样,然后就是让脚本一直循环,持续运行一段时间,看性能数据。
这是启2个线程跑的,可以看到,比之前全是一样的请求时,性能下降了。
这是我整理的《2024最新jmeter接口测试和jmeter接口自动化测试全套教程附带性能测试》,以及配套的接口文档/项目实战【网盘资源】,需要的朋友可以下方视频的置顶评论获取。肯定会给你带来帮助和方向。
b站最新最全的jmeter接口测试和jmeter接口自动化测试,jmeter性能测试保姆级全套教程!