救命！像图中这样的Vuser和TPS的关系我难以理解

athukira

就是下面这张图，绿色是Running user，其余的线是不同的几个事务。

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

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

chare

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


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

love_yebin

这快要看你的服务器资源，或者说是数据库资源的相关信息，最好把数据库的信息发出来
看看 系统有没有在做别的

chenyingli

同意楼上，我遇到DB server上在run report或者web server上run backup，都是schedule好的，所以资源全占了。

athukira

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

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




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

love_yebin

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

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

zynuage

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

athukira

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

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

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

Lotus.L

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

athukira

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

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

总之谢谢各位的建议！

love_yebin

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


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

这里面的图

love_yebin

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

mr.bee

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

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

athukira

是指web page diagnostics里面的图？原来如此，我试试。

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

星驰

楼主的系统内存泄露！

athukira

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


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

athukira

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

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

mr.bee

硬件资源已经没什么占用了（看你楼主的图得出）
点击率 吞吐跌至0（看楼主的图得出）
虚拟用户不断下降 响应时间仍然不断增加（听楼主说的）

这是内存泄漏的主要特征

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

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

athukira

一般不是说process\private bytes计数器和process\working set 计数器的值往往会升高,同时available bytes的值会降低的吗？没有这样的现象啊。。

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

athukira

用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 编辑 ]