51Testing软件测试论坛

标题: Loadrunner web_concurrent_end_action 性能分析 [打印本页]

作者: serina03 时间: 2011-7-21 13:52
标题: Loadrunner web_concurrent_end_action 性能分析
看到论坛中有前辈提出过关于 web_concurrent_end_action的问题。

最近在做性能测试的过程中遇到了类似的问题。

某事物响应时间平均超过了150s。

1. 在analysis中查看该页面breakdown的时候，发现 web_concurrent_end_action XXXX会占用接近40%的响应时间。

2. 然后查看web_concurrent_end方法解释为：
web_concurrent_start函数是并发组开始的标记。组中所有的函数是并发执行的。并发组的结束web_concurrent_end 函数。在并发组开始时，所有的函数首先被记录下来，当并发组结束时，所有的函数并发执行。脚本执行时，碰到 web_concurrent_end函数时，开始并发执行所有记录的函数。可以并发执行的函数的个数是有限制的，使用运行时设置-Netword标签页的Concurrent Connection来设置。

3. 再查看服务器内存使用情况，page cache使用率达到20% 上网查了下，该指标应低于14%。
ps: Anon < 60%
cpu < 20%

4. 最后查看LR Controller--Run time setting, Clear cache on each iteration 为勾选中。

所以我得出以下猜测：
1. 根据各项硬件指标，初步得出结论，app server硬件应该不是瓶颈。
2. web_concurrent_end 所占响应时间占总响应时间如此之高，是否说明该性能测试结果不准确？
3. web_concurrent_end 是否就是去清除这些大量的cache导致了响应时间的增加？

请教各位前辈啦...

作者: serina03 时间: 2011-7-21 19:36
顶啊...没人回复么？好桑心...

作者: 放任无奈 时间: 2011-7-21 21:24
关注 web_concurrent中就是对资源文件做请求吧?
可以把并发组内的脚本贴一下看看

作者: serina03 时间: 2011-7-22 23:10
回复 3# 放任无奈
今天又仔细细分了 web_concurrent_end ,发现都是 js, css和图片得加载。
所以，初步得出结论是这是加载页面的io读写的响应时间。
不知道这样分析对不对？？

作者: hclovezz1314 时间: 2011-7-25 09:39
不知道你是什么系统的，如果是linux系统，那你直接用vmstat命令监控 IO CPU 内存，

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