关于Average Troughout的疑惑

cafard-haibin

【操作描述：】
步骤1：录制了一个网站的首页，通过检查loadrunner的录制日志计算出脚本单词运行时的Average Troughout是7623K/s；
步骤2：在场景中设置了1个用户跑下下：Average Troughout是7623K/s;
步骤3：在场景中设置了100个用户，并且10秒加载20个虚拟用户，每5秒跑2个虚拟用户。运行后Average Troughout是1852K/s；

【问题】
我在写测试报告中时如果写：Average Troughout是1852K/s是不是太不准确了。如果写了，该怎么给别人解释呢？

lisaxu

帮顶，我也想知道

Oolong

我觉得是因为并发量大导致的，当并发量大时，可能有请求堆积的情况，导致平均吞吐量反而变小了，建议可以做下试验，从10个并发开始，10个10个加上去，每次加之前先看平这个值的情况，再加10个之前建议跑个3分钟左右看下情况，可能会看到加到一定程度，这个值会开始在走下坡路，那应该就是出现请求堆积，程序反而处理不过来的情况吧。个人意见，你可以试试看，回头把结果告诉我一下啊～～

cafard-haibin

原帖由 Oolong 于 2009-9-18 12:01 发表
我觉得是因为并发量大导致的，当并发量大时，可能有请求堆积的情况，导致平均吞吐量反而变小了，建议可以做下试验，从10个并发开始，10个10个加上去，每次加之前先看平这个值的情况，再加10个之前建议跑个3分钟左右看 ...

感谢您的回复。请注意我的场景中用户是逐渐加载的。且脚本中没有集合点。所以我感觉是因为虚拟用户运行完就不和服务器打交道了。也就没有流量。而这样逐渐加载的话肯定运行时间很长，这样用总吞吐量除以总时间得出的平均吞吐量可能就比较小了。不知道是不是这样。如果是，那就是在进行以网络吞吐量为性能指标的测试时场景设计就不能采用这种形式是吗？

Oolong

关于你这个问题我做了个实验，设置2个场景，一个场景是10个并发10分钟，在场景开始时，10个并发一起跑，第二个场景是10个并发10分钟，设置1分钟启动一个并发。那要等到第9分钟的时候10个并发才全部启动完，从第9分钟开始才是10个并发一起跑，那我观察结果是这样的：
第一个场景的THROUGHPUT平均值：1576500.271，第二个场景的THROUGHPUT平均值：1224463.537，
并且我发现第2个场景实际是运行了19MIN，那我认为LR设置并发10分钟，他是默认为用户最少运行时间至少为10分钟就停下来，也就是第10个用户在第9分钟启动，那持续跑10分钟到第19分钟，停。
这样，我认为在进行以网络吞吐量为性能指标的测试时场景设计就不能采用这种形式，因为多了前面那一段，但要采用这种形式的话当然也可以的。因为LR的ANALYSIS有一个AUTO CORRELATE的功能，可以选择你关注的时间段，只要在ANALYSIS的THROUGHPUT图表上，右键单击后选择AUTO CORRELATE，在弹出的图中，选择10个用户集合的那个时间点开始，再确定即可得到你想要的指标，我这样做了以后，得到的第二个场景的THROUGHPUT平均值：1590882.471，与第一个差不多。：）你试试吧

村上舞!舞!舞

…………

[ 本帖最后由 村上舞!舞!舞 于 2009-9-21 12:34 编辑 ]

Oolong

楼上的你干吗。。。。。

村上舞!舞!舞

回答的不错。动手实验过的东西，就是要支持。问题已经很明确了，不知楼主是否已经明白

cafard-haibin

原帖由 Oolong 于 2009-9-21 12:19 发表
关于你这个问题我做了个实验，设置2个场景，一个场景是10个并发10分钟，在场景开始时，10个并发一起跑，第二个场景是10个并发10分钟，设置1分钟启动一个并发。那要等到第9分钟的时候10个并发才全部启动完，从第9分钟 ...

不知用什么语言来感谢你，我就喜欢这样不断的实验。只可以自己没有想到你这个思维方式。再次感谢了。此问题已经解决，就不再讨论了。