51Testing软件测试论坛

标题: 救命！像图中这样的Vuser和TPS的关系我难以理解 [打印本页]

作者: athukira 时间: 2009-2-20 17:48
标题: 救命！像图中这样的Vuser和TPS的关系我难以理解
[attach]49276[/attach]就是下面这张图，绿色是Running user，其余的线是不同的几个事务。

为什么随着时间增长，运行用户减少，事务响应时间反而那么大了呢？

[ 本帖最后由 athukira 于 2009-2-20 17:52 编辑 ]

作者: chare 时间: 2009-2-20 22:58
为什么随着时间增长，运行用户减少，事务响应时间反而那么大了呢？

如果正常的话。还需要去做性能测试。去监控吗？
就是有问题。才要去查找原因

作者: love_yebin 时间: 2009-2-20 23:01
这快要看你的服务器资源，或者说是数据库资源的相关信息，最好把数据库的信息发出来
看看系统有没有在做别的

作者: chenyingli 时间: 2009-2-21 00:09
同意楼上，我遇到DB server上在run report或者web server上run backup，都是schedule好的，所以资源全占了。

作者: athukira 时间: 2009-2-22 15:54
这个场景是100个Vuser并发，我只录了一个action，把它分为两个事务。一个是域登录，一个是通过域登录之后的下载显示页面。
然后是默认的将action也作为一个事务。（我不知道怎么取消这个默认。。。）

域登录的那条线几乎与action的线重叠了。
看起来瓶颈似乎是域登录。
执行场景的时候，error提示的大部分是与域登录的那台服务器的80端口连接超时，或者拒绝连接。

[attach]49289[/attach]

但是具体原因要怎么分析呢？看windows资源图我看不出来。。。。T3T
[attach]49290[/attach]

作者: love_yebin 时间: 2009-2-23 13:17
action是整个脚本得执行时间，这个和你要测的无关，
你要明白你测的是域登录
如果是这样得话，
在输入用户名和密码后，插入事务“登录 ”
点击登录后，IE 状态栏显示完毕，
结束“登录”

不可能说你把登录和后面得下载分开，这个我还没做过，不知道哦能行不？
但是针对这个登录得事务得响应时间是你的结果
还有这个如果时间长就分析 time download里面的图，
windows资源图，只是反映你系统并发用户数占用得系统资源情况

作者: zynuage 时间: 2009-2-23 14:02
你总共加载了100个虚拟用户，不知道是否加入集合点儿，有可能压力过大，造成的服务器没有响应，你可以屏蔽集合点和减少用户数试试。

作者: athukira 时间: 2009-2-23 14:37
回楼上，减少用户数和屏蔽集合点只能使响应时间降低，但是域登录这个事务的响应时间仍然是随着时间几乎线性增长诶。。。

回复love_yebin：你说的有道理，我去修改一下脚本，照你说的去做，结果应该更准确点儿。
time download图？是指哪个图啊？

[ 本帖最后由 athukira 于 2009-2-23 15:00 编辑 ]

作者: Lotus.L 时间: 2009-2-24 10:22
楼主，我观察了你的ATR-Running Vuser 的图，发现整个测试场景只运行了55秒，而且你的user load 从0个用户直接增加到100个用户，有可能web服务器或者验证域名的服务器暂时没有响应，因为突然增加的用户数过大，从而导致事务响应时间增加，服务器拒绝连接。
有几点建议：
1. 建议增加用户的时候设置 ramp up, 比如每15秒钟增加5个用户。
2. 建议增加场景运行时间。有助于数据的生成更真实，更能准确反映服务器和应用的性能。

作者: athukira 时间: 2009-2-24 11:21
回复楼上，user load 从0个用户直接增加到100个用户，是因为我想测最大并发数，所以设置的集合点。如果设置ramp up，怎么判断它的最大并发呢？

关于增加场景运行时间，我也做了这样的考虑，但是原本是想把上面的问题解决了再做的

总之谢谢各位的建议！

作者: love_yebin 时间: 2009-2-24 13:23

原帖由 athukira 于 2009-2-23 14:37 发表

回复love_yebin：你说的有道理，我去修改一下脚本，照你说的去做，结果应该更准确点儿。
...

这里面的图

作者: love_yebin 时间: 2009-2-24 13:24

把我电脑上的东西都给你们看见了

作者: mr.bee 时间: 2009-2-24 13:48
1. 2楼等于没回答
2. 在你两个事务中插入检查点确认已执行
3. 确认应用于数据库没出现硬件瓶颈（目前没看到数据库资源图）
4. 降低压力再测看看（10个、50个）看看有没类似情况发生
5. 如Lotus.L 所说的：慢慢加载至100，延长点持续时间

还差吞吐量和点击率图
我感觉是发生内存泄漏

作者: athukira 时间: 2009-2-24 13:50
是指web page diagnostics里面的图？原来如此，我试试。

放心，你电脑上的东西，也看不出什么来啦～

作者: 星驰 时间: 2009-2-24 14:05
楼主的系统内存泄露！

作者: athukira 时间: 2009-2-24 14:36
回复Mr.bee：
1、略
2、我已经修改脚本只保留域登录的事务，去掉了下载。
3、数据库资源图是哪个？要使用哪些计数器？。。。我一直以为是系统资源图里面添加SQL server类的计数器就可以了。。。我在其他执行的场景里面有添加，不过看不出个所以然来＝＝
4、降低压力到50，并发结果还是一样的现象。
5、即时慢慢加载到100，延长持续时间，响应时间从趋势上也是随时间增大，尤其是最后几个点，运行用户已经释放到不足15个，响应时间却从11s飙升到56s。
6、吞吐量和点击率感觉还正常啊，如下图，绿色是点击率，紫色是吞吐量：
[attach]49361[/attach]

[ 本帖最后由 athukira 于 2009-2-24 15:00 编辑 ]

作者: athukira 时间: 2009-2-24 14:37

原帖由星驰于 2009-2-24 14:05 发表
楼主的系统内存泄露！

诶诶？！！怎么判断出来的？？

作者: mr.bee 时间: 2009-2-25 13:15
硬件资源已经没什么占用了（看你楼主的图得出）
点击率吞吐跌至0（看楼主的图得出）
虚拟用户不断下降响应时间仍然不断增加（听楼主说的）

这是内存泄漏的主要特征

建议调整场景进行测试确认一下
比如把降低到10个用户并发测试

bbs上讨论由于掌握的信息有限
主观因素影响较大
如果哪里说得不对欢迎指出

作者: athukira 时间: 2009-2-25 14:12
一般不是说process\private bytes计数器和process\working set 计数器的值往往会升高,同时available bytes的值会降低的吗？没有这样的现象啊。。

那么我去用10个并发试一试吧～

作者: athukira 时间: 2009-2-25 14:45
用10个并发，Duration设置为ramp up完成后持续5分钟，响应时间终于不是线性上升了T，T
响应时间最小0.4，最大1.35，平均0.86
在2分16秒达最大。然后下降。

10个用户在0s就集合完开始运行，到第5分钟同时释放。
点击率在32s达到最大，吞吐量40s达到最大，两者增降都正常。
CPU平均利用率8.5％
硬件资源占用比较少。

[ 本帖最后由 athukira 于 2009-2-25 14:48 编辑 ]

作者: mr.bee 时间: 2009-2-25 19:54
那你的看法是？

作者: athukira 时间: 2009-2-26 14:15
我。。。。没想法

是内存泄露还是压力过大还是什么原因。。。？

不管什么原因，都要考虑怎样调优了。。。

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)