为什么同样的场景条件下，并发用户数50的事务平均响应时间比30还要小？

stevenhappy · 发表于 2007-5-31 09:26:59

为什么同样的场景条件下，并发用户数50的事务平均响应时间比30还要小？
脚本:都是同样一个脚本,在脚本设置了三个事务和集合点.
场景设置:
设置事物和并发,考虑了思考时间，50个并发用户数的场景运行时间是10分钟,30个并发用户数的场景运行时间是5分钟.

Zee · 发表于 2007-5-31 09:34:10

看是哪里用了时间！

csl2005 · 发表于 2007-5-31 09:46:47

不懂哦，高手解答下～～～

stevenhappy · 发表于 2007-5-31 10:12:18

到哪里去看占用的时间？能否具体点讲解下？？sdlkfj2 sdlkfj2 sdlkfj2

bingbingyang11 · 发表于 2007-5-31 10:58:24

看到许多人出现了这方面的问题
我想说明一下的是，lr毕竟是测试工具，虽然能模拟现实生活中的场景，但不能做到100%尽如人意，我搜索了以下一些资料，希望对楼主有帮助：
在 LoadRunner 中，千万不要想当然地以为设置了 100 个并发用户数，它就会每秒向服务器提交 100 个请求，这是两个不同的概念，因为 LoadRunner 模拟客户端向服务器发出请求，必须等待服务器对这个请求做出响应，并且客户端收到这个响应之后，才会重新发出新的请求，而服务器对请求的处理是需要一个时间的。我们换个说法，对于每个虚拟用户来说，它对服务器发出请求的频率将依赖于服务器对这个请求的处理时间。而服务器对请求的处理时间是不可控的，如果我们想要在测试过程中维持一个稳定的每秒请求数（ RPS ），只有一个方法，那就是通过增加并发用户数的数量来达到这个目的。这个方法看起来似乎没有什么问题，如果我们在测试场景中只执行一次迭代的话。然而有经验的朋友都会知道，实际情况并不是这样，我们通常会对场景设置一个持续运行时间（即多次迭代），通过多个事务 (transaction) 的取样平均值来保证测试结果的准确性。测试场景以迭代的方式进行，如果不设置步进值的话，那么对于每个虚拟用户来说，每一个发到服务器的请求得到响应之后，会马上发送下一次请求。同时，我们知道， LoadRunner 是以客户端的角度来定义“响应时间”的，当客户端请求发出去后， LoadRunner 就开始计算响应时间，一直到它收到服务器端的响应。这个时候问题就产生了：如果此时的服务器端的排队队列已满，服务器资源正处于忙碌的状态，那么该请求会驻留在服务器的线程中，换句话说，这个新产生的请求并不会对服务器端产生真正的负载，但很遗憾的是，该请求的计时器已经启动了，因此我们很容易就可以预见到，这个请求的响应时间会变得很长，甚至可能长到使得该请求由于超时而失败。等到测试结束后，我们查看一下结果，就会发现这样一个很不幸的现象：事务平均响应时间很长，最小响应时间与最大响应时间的差距很大，而这个时候的平均响应时间，其实也就失去了它应有的意义。也就是说，由于客户端发送的请求太快而导致影响了实际的测量结果。

stevenhappy · 发表于 2007-5-31 11:16:56

谢谢楼主的详细回答。出现我刚才的问题，说真的还是不知道往哪方面去分析？

bingbingyang11 · 发表于 2007-5-31 11:23:39

我可不是楼主
you 才是
你可以设置pacing试试，也就是步

stevenhappy · 发表于 2007-5-31 11:55:49

我想请你说的详细点，真的很麻烦你了。sdlkfj2 sdlkfj2

bingbingyang11 · 发表于 2007-5-31 13:30:03

首先我不知道这样操作能不能解决你说的那个问题，只是试试而已，如果不行可以再想别的办法，向开发人员咨询下，在运行时看哪里用去了时间，发生这个问题有很多可能
在运行设置里，general-〉pacing-〉start new iteration里切记不要选择第一个，最好选第二个，然后设置一个延迟时间，再在controller中运行

stevenhappy · 发表于 2007-5-31 14:12:25

好的，非常谢谢。要是多个人来讨论就更好些，在测试方面我们需要多多地交流和讨论，这样进步才快。

bingbingyang11 · 发表于 2007-5-31 14:33:15

嗯，如果楼主有解决办法了，别忘了通知俺，也好学习下

Athenst · 发表于 2007-5-31 15:01:08

sdlkfj3

ppent · 发表于 2007-5-31 15:19:23

“在测试过程中维持一个稳定的每秒请求数（ RPS ）”，这是作为开发视角进行调优才需要的吧，作为楼主从业务视角来性能测试来说我认为是不需要的。

stevenhappy · 发表于 2007-5-31 17:45:11

不是的，我想知道为什么在同样的场景条件下，并发数大的平均响应时间反而比并发数小的平均事务响应时间要小？？我想知道如何取分析问题？从哪些方面去分析？

shanxi · 发表于 2007-5-31 17:49:10

首先你得弄清楚

你操作LR取得的相应时间就是真实的你可以依据的时间吗？

你至少给个analyse的分析data吧，凭空神仙才能知道你所谓的条件确实是可靠的？

[ 本帖最后由 shanxi 于 2007-5-31 17:50 编辑 ]

stevenhappy · 发表于 2007-6-1 08:57:30

好的，下面是50和30并发用户数的数据:
见附件：50.jpg,30.jpg

shanxi · 发表于 2007-6-1 09:49:08

你可以多跑几次

再看分析的结果

analyse里面的结果是汇总了一个场景所有运行次数后综合的

50个用户跑了一次 30个用户也跑了一次比较
50个用户跑了二次 30个用户也跑了二次比较

50个用户跑了一次 30个用户也跑了二次比较区别你应该知道

跟统计学有关

stevenhappy · 发表于 2007-6-1 09:54:37

谢谢你的回答。sdlkfj2 sdlkfj2 sdlkfj2

andy · 发表于 2007-6-1 09:56:17

我觉得你的测试结果挺正常的啊!除了queryFinish 事务有响应时间一点点长而已,这个也算是正常的范围,不会太夸张.

另外你能详细介绍一下你测试运行的场景吗?你是不是没有设置运行时间,设置了duration -> run until completion?

stevenhappy · 发表于 2007-6-1 10:07:03

设置场景的运行时间:
50个并发数是持续到10分钟,30个并发数是持续到5分钟;我现在要给他们说明的是:为什么有两个事务50个的并发数比30的并发数要小？按理来数50个并发数比30个的并发数要大才对的.

		自动登录	找回密码
密码			(注-册)加入51Testing

[求助] 为什么同样的场景条件下，并发用户数50的事务平均响应时间比30还要小？

相关帖子

本帖子中包含更多资源

站长推荐 /1