关于LR场景中,最大响应时间与最小响应时间差距大的问题

场景设置: 一个Vuser 完成登录退出操作,执行时间为5分钟

result: 最大响应时间与最小响应时间,差距超大(120s,0.7s)

解决办法: 出现此情况为Run-Time settings -->General -->Pacing 没有配置

  转载

其实LoadRunner 是以客户端的角度来定义“响应时间”的,当客户端请求发出去后, LoadRunner 就开始计算响应时间,一直到它收到服务器端的响应。这个时候问题就产生了:如果此时的服务器端的排队队列已满,服务器资源正处于忙碌的状态,那么该请求会驻留在服务器的线程中,换句话说,这个新产生的请求并不会对服务器端产生真正的负载,但很遗憾的是,该请求的计时器已经启动了,因此我们很容易就可以预见到,这个请求的响应时间会变得很长,甚至可能长到使得该请求由于超时而失败。等到测试结束后,我们查看一下结果,就会发现这样一个很不幸的现象:事务平均响应时间很长,最小响应时间与最大响应时间的差距很大,而这个时候的平均响应时间,其实也就失去了它应有的意义。也就是说,由于客户端发送的请求太快而导致影响了实际的测量结果,设置步长则可以缓解这一情况,这样,应该试试设置pacing,再运行看看情况

 

后尝试配置pacing为delay30s, 场景结果有所改变。需要仔细了解其中原理。

 

下面这篇文章是具体的讲解分析

http://www.blogjava.net/xingcyx/archive/2006/12/28/90498.html

 

http://www.51testing.com/html/36/n-170436.html

  • 0
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值