loadrunner模拟的虚拟并发用户为什么会全部通过？

zhong51test

loadrunner模拟的虚拟并发用户数分别为20，40，60，80，100为什么全部会通过呢，居然没一个失败的用户，而且每个用户最少运行时间都是1分钟以上，比实际操作实际长多了，很郁闷！祈求大师们帮忙。

iori

录制的什么操作？详细描述一下

zhong51test

谢谢，上传图片及人脸识别。可单独看做是图片上传吧

[ 本帖最后由 zhong51test 于 2008-11-25 11:30 编辑 ]

iori

脚本中有无thinktime，每个用户的运行时间你是怎么得出来的，把结果截图上来

zhong51test

我没设置IP欺骗，这不会影响上述结果吧？

zhong51test

有think_time,我查看每个用户的elaspsed time

不好意思啊，公司限制了，外网上传不了文件。

[ 本帖最后由 zhong51test 于 2008-11-25 11:59 编辑 ]

zhong51test

think_time时间是录制时候带进的，72
我设置的是，Multiply recorded think time by:1

zhong51test

噢，我明白了，用户运行时间需要减去think_time时间对吗？如果是这样应该差不多。但为什么用户能全部都通过呢，这个我不太明白。

jlsv

看到楼主说是上传文件操作, 那么楼主是怎样判断用户操作是成功还是失败的呢?

另外 楼主你的意思是不应该100个用户并发会成功是吧, 那么你们的系统预定是能够支持多少个用户呢? 这么多用户上传文件又是否上传正确呢? 上传的时间是否又符合要求呢? 建议楼主看看.

zhong51test

非常感谢二位的帮忙，对本人有不少帮助。我大概明白了。如果  用户响应时间= 用户运行时间-think_time时间的话，我大概算了下，20个并发用户
有3个在5秒之内能完成，11个在10秒之内完成。全部完成需要13秒，估计上传时间不符合系统要求。


我怎么才能看出所有用户文件都上传成功了呢，因为我是录制的脚步，录的时候是上传成功了的，这能代表通过用户数文件上传成功了吗？

运行环境：loadrunner和程序服务均在本机子上运行，这可能会造成些影响吧，因为都有资源开销。现在公司还没算出预定支持用户数哟，

[ 本帖最后由 zhong51test 于 2008-11-25 13:26 编辑 ]

jlsv

你测试的系统上传成功结束之后有没有显示成功的画面呢? 有的话, 可以通过检查服务器返回的信息或者是图片来验证是否上传成功.

另外, 楼主你计算 用户响应时间= 用户运行时间-think_time

我觉得你这个想法可能不太好, 我们关注的响应时间一般就是提交请求到返回请求这一段时间, 通俗来说就是点击提交按钮后到页面完全显示页面后所用的时间, 这段时间内是没有用户操作的才对, 这才是一个原子性的操作(这个所谓的原子性操作是我瞎掰出来的, 并没有这个概念, 楼主你明白就行 ),所以不应该有think_time存在, 如果按照楼主你的响应时间计算方法, 看上去就像是把好多个原子性的操作一起计算时间了, 这样感觉没有太大意义呢.

zhong51test

看来，用户响应时间我还是计算错误，那么大家是怎么计算每个用户的‘响应时间’呢，每个用户的‘elaspsed time’到底是什么时间呢？如过这个时间就是用户响应时间的话，那应该不对，太长了。

[ 本帖最后由 zhong51test 于 2008-11-25 17:33 编辑 ]

creatysun

在runtime设置里可以让虚拟用户运行时不考虑thinktime，加上thinktime再并发肯定比实际操作时间久啊。

附件管理一般会有编码，在服务器端会有一定的存取规则，到文件服务器上看看就知道了。不过通常情况下，没有手动关联处理是无法写入的

[ 本帖最后由 creatysun 于 2008-11-25 18:03 编辑 ]

jlsv

上面已经说过了, 我们关注的响应时间一般就是页面提交请求到返回请求页面显示这一段时间, 通俗来说就是点击提交按钮后到页面完全显示页面后所用的时间

可以粗略认为
(loadrunner里面的)响应时间 = 客户端发送请求至接收回应
(我们关注的)响应时间 = (loadrunner里面的)响应时间 + 应用呈现页面所用的时间

13楼的朋友, 你说"在runtime设置里可以让虚拟用户运行时不考虑thinktime，加上thinktime再并发肯定比实际操作时间久啊。", 我不完全同意你的观点, 在脚本里加入think time 是为了更准确地模拟用户的操作, 和能否准确地计算"响应时间"没有直接的联系. 因为我们计算响应时间都是某一步操作所用的时间, 中间不会再有用户操作, 自然也不会受 think time 的影响.

[ 本帖最后由 jlsv 于 2008-11-26 09:50 编辑 ]

zhong51test

14楼朋友说的很在理，但是我发现存在thinktime的时候，响应时间的确比没有thinktime的时候长，比较controller里的Trans Response Time 时间可以看得出。而且这里只能看到最长响应时间、最短响应时间和平均时间，看不出每个用户的响应时间。Trans Response Time 应该可以算是(loadrunner里面的)响应时间也可以算是(我们关注的)响应时间吧

13楼的朋友说法我比较赞同，上传图片后，在服务器端会有一定的存取规则，因为很明显同一张图片上传后URL已经改变。我该如何手动关联呢。因为我想保持图片相关参数的传递始终动态从服务器取。

Simatu

要看相应时间的话，对上传文件这个操作设一个事务，然后再看完成这个事务完成所需要的时间。这样理解呢？

zhong51test

完成这个事务所需要的时间你是指运行结束后的‘运行时间’elapsed time还是Trans Response Time 呢？

Simatu

恩，提醒我了！我要把ThinkTime去掉比较下看看

jlsv

但是我发现存在thinktime的时候，响应时间的确比没有thinktime的时候长
------
一般来说, 脚本中有think time 对服务器的压力会小些, 一般会使响应时间小些或者差不多.


比较controller里的Trans Response Time 时间可以看得出。而且这里只能看到最长响应时间、最短响应时间和平均时间，看不出每个用户的响应时间。
--------------
一般我们注意的是运行时用户响应时间是否平稳, 是否达到我们的需求, 这些可以从最长响应时间、最短响应时间和平均时间中看出来. 不需要针对某个特定用户, 因为运行某个功能的所有用户都是一样的, 我们只需要知道趋势就可以.

Trans Response Time 应该可以算是(loadrunner里面的)响应时间也可以算是(我们关注的)响应时间吧
-----------------------
不一样的, Trans Response Time 就是(loadrunner里面的)响应时间,
(我们关注的)响应时间其实更准确来说是用户感觉的响应时间.
不过因为后者包括前者, 所以用前者的变化可以间接知道后者的变化

zhong51test

朋友你描述的比较准确，让我更清晰这些时间概念。


脚本中有think time 对服务器的压力是应该会小些,但 我观察这种情况下，Trans Response Time 时间的确更长。