性能测试工具 用 Jmeter 工具压测上传文件接口的过程和自己的一些疑问,希望有高人能指点一下

肥猫 · 2017年11月27日 · 最后由 Baozhida 回复于 2017年12月11日 · 5172 次阅读

遇到的疑问以及自己的思考(不一定对,希望知道的人可以说两句:)

1、 当并发线程数设置越大时(100--200--300),TPS 反而越低,但前后台都没有报错,服务器的资源占用也可以忽略不计

个人认为原因:因为网络带宽原因限制了,当线程数在增加时,同样时间内请求发送的数量越来越少,压力并没有到后台服务器,时间都消耗在了上传文件这个阶段

2、 每次当并发数到 400 左右的时候(不管是单台机压 400,或者是五台客户机搞分布式压 400,又或者是每个客户机独立同时向服务器发 80),总是会报错,错误信息都是一样
java.io.IOException: Error writing to server

在网上也看了一些解决办法,但还是没有解决,比如修改 jmeter.bat 文件里的 HEAP 的大小

个人认为原因:每个请求时间过长,2-3 分钟发不一个请求,导致启动的连接都在客户机,发不出去,然后端口占用完了,才会报错,因为每次报错的时候,端口都用到了 6W 开头了,如图,但我用 netstat -ano 去查看,一共才几百个端口,不知道用什么命令可以把所有占用的端口都显示出来,不知道为什么 4W 多的端口用了几十个,一下子就跳到了 5W 多的端口,然后又跳到 6W 多的端口,希望知道的高手能指点一下像我这种小白

脚本编写:

因为没有涉及 cookie,token,加密之类的操作,就简单的一个上传文件的接口,所以脚本也很简单,
看图就 OK
1、直接在测试计划中新建一个线程

2、然后在线程组中新建一个 http 请求

3、填写需要压测的接口和参数等内容

4、 到 Advanced 标签页选择请求的方式,通过 Java 方式发送请求

5、这样就可以发送请求到服务器了,但我们还想看到我们发过去的请求内容和服务器返回给我们的内容,所以要添加一个监听器类型的控件,比如 “查看结果树”

6、添加完查看结果树后,我们发送一次请求,然后到结果树查看发送过去的请求和服务器返回的数据


7、绿色代表成功,红色代表失败,如果失败,要排查就我们发过去的内容和服务器返回的内容来定位,具体问题具体分析

8、下一步,我们再添加一个断言,根据我们自己的定义来判断,什么时候是成功,什么时候是失败


9、再下一步,我们再添加一个监听类型,统计我们的压测结果,比如聚合报告

10、 执行之后,我们就可以在聚合报告里查看结果

11、参数化

添加一个 CSV 文件配置

然后在本地新建一个 csv 文件,里面填上要上传文件的路径

  • 然后修改 CSV 文件配置,选上刚刚建的 CSV 文件和其它的配置信息

最后修改一下发送请求的文件

12、关于多台机发布式时的问题:

  • 执行机(slave)要到 bin 目录下的:jmeter-server.bat,启动该执行机
  • 执行机 IP 的配置,在 jmeter.properties 里配置
  • 需要需要在察看结果树里看到执行机的发送请求之后服务器返回的响应数据

要在 jmeter.properties 里配置打开标准模式,如图

共收到 5 条回复 时间 点赞

图片全都看不到哦。

donly 回复

再试试???之前用的是有道的共享图片,可能是 testerhome 不允许访问非 testerhome 的图片吧,现在用了 testerhome 自己的

恩,可以看到图片了

我也是小白,所以具体原因我也没法帮你。前些日子我测试时也遇到类似的问题,服务器压力很小,但是线程数增加,响应时间就等比增加。只是没有出错。
查看结果树里面的时间,lantency 占了 loadtime 的绝大部分。猜测是排队时间过长,但最终开发也没有定位到原因何在。

tps 最多才是 5.5 ,并发 90 就很离谱了,更别说 400 了,95% 的请求都在积压状态。关键看 tsp 为何这么低

性能测试为了找到系统的极限,并发数据已经远远超过了系统的承受能力。

还有接口响应时间 都好几十秒了。就不要看这个数据了。

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册