51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 2648|回复: 4
打印 上一主题 下一主题

[原创] Loadrunner web_concurrent_end_action 性能分析

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2011-7-21 13:52:17 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
看到论坛中有前辈提出过关于 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导致了响应时间的增加?

请教各位前辈啦...
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

该用户从未签到

2#
 楼主| 发表于 2011-7-21 19:36:34 | 只看该作者
顶啊...没人回复么?好桑心...
回复 支持 反对

使用道具 举报

该用户从未签到

3#
发表于 2011-7-21 21:24:14 | 只看该作者
关注 web_concurrent中就是对资源文件做请求吧?
可以把并发组内的脚本贴一下看看
回复 支持 反对

使用道具 举报

该用户从未签到

4#
 楼主| 发表于 2011-7-22 23:10:03 | 只看该作者
回复 3# 放任无奈
今天又仔细细分了 web_concurrent_end ,发现都是 js, css和图片得加载。
所以,初步得出结论是这是加载页面的io读写的响应时间。
不知道这样分析对不对??
回复 支持 反对

使用道具 举报

该用户从未签到

5#
发表于 2011-7-25 09:39:50 | 只看该作者
不知道你是什么系统的,如果是linux系统,那你直接用vmstat命令监控 IO CPU 内存 ,
回复 支持 反对

使用道具 举报

本版积分规则

关闭

站长推荐上一条 /1 下一条

小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

GMT+8, 2024-11-13 03:34 , Processed in 0.104901 second(s), 28 queries .

Powered by Discuz! X3.2

© 2001-2024 Comsenz Inc.

快速回复 返回顶部 返回列表