LR结果中receive时间长的原因是什么
用的是LR8.1,录制方式选择的是URL，脚本很简单就一个页面的URL，如下所示：web_url("xx.x.cn",
"URL=http://xx.x.cn/",
"Resource=0",
"RecContentType=text/html",
"Referer=",
"Snapshot=t1.inf",
"Mode=HTTP",
LAST);
50个用户并发，全部成功。响应时间为34.2秒。查看网页细分图显示的receive时间比较长，其他的没有异常。在局域网内，此原因如何分析呢？ 请问DB到SEARCER的通讯时间怎么样？其它的如：各服务器的相关性能参数如：CUP平均占用率，峰值怎么样，正常吗，你测试时有几层架构，LR 直接到了应用服务器还是？ 响应延迟？ 原帖由 骄阳似火 于 2010-6-24 13:32 发表 http://bbs.51testing.com/images/common/back.gif
请问DB到SEARCER的通讯时间怎么样？其它的如：各服务器的相关性能参数如：CUP平均占用率，峰值怎么样，正常吗，你测试时有几层架构，LR 直接到了应用服务器还是？
谢谢回复，我从你说的这几方面再看一下 做压力测试除了观察LR上的结果以后，同时还得观察主机资源和LR客户机资源，以及网络情况，如果以局域网的情况来说，一般看主机资源和LR结果就可以。
建议在压力测试时：
1、从小并发往上压，看相应时间走势，以及吞吐量的走势；
2、同时观看主机资源，如果主机资源一直空闲的话，要看应用服务器和数据库的配置信息等。 1网页细分
2检查响应时间是不是包含了不必要的时间 因为测试服务器上没有配置，现在无法填加资源监控。只是一个URL，其网页细分图如下：
在此之前是因为有好多图片，看到都是图片下载时间过长的原因，现在是去掉图片的信息，只是单纯的URL，receive时间仍旧是很长。
[ 本帖最后由 hbxtly 于 2010-6-25 10:45 编辑 ] 大家帮我看下资源图吧，CPU是一个原因吗？
感觉是应用配置问题 建议楼主把TPS,响应时间和throughput的图贴上来，我看下~！！
你在测试环境中，去观察网页细分，貌似没什么效果
你研究的方向错了~！！网页细分，大多描述的是网络上面的问题，看不出什么太大的效果的
给你一些别的方向吧：
1。可以去查一下，你的jdbc连接数，看看有多大，是否支持你的虚拟用户数
2。如果jdbc设置的连接数足够大了，那么你可以去观察一下数据库，看看是否有死锁的情况
3。在去看看你中间件设置的线程数，看看是否足够大。
[ 本帖最后由 zl861216 于 2010-6-30 17:21 编辑 ] receive时间长，检查网络通信质量吧
也有可能是应用中涉及到IP、机器名的解析，这个要问问开发人员
数据库、web应用服务器不用看了
可以考虑换个网段部署测试环境来验证
[ 本帖最后由 tttrrryyy 于 2010-7-2 16:49 编辑 ] 把你的网卡配置改下
Speed&Duplex ：Auto
如果你把这个设置为100MB full 的话有时候是会很长时间的 原帖由 zl861216 于 2010-6-30 16:49 发表 http://bbs.51testing.com/images/common/back.gif
建议楼主把TPS,响应时间和throughput的图贴上来，我看下~！！
你在测试环境中，去观察网页细分，貌似没什么效果
你研究的方向错了~！！网页细分，大多描述的是网络上面的问题，看不出什么太大的效果的
给你一 ...
三个图如下所示：
回复 13# 的帖子
为什么你的TPS从一开始就是平的啊，你试试，每30秒加一个用户，加到50，看看曲线变化的趋势。。仔细观察，用户数增加时，TPS是否增加，如果不增加，你可以去看看中间件或者jdbc等连接数的设置，我怀疑是那里设置了最大连接数。 到底这个问题是怎么解决的，好奇下。
不过我觉得应该是网络问题，你可以通过内网、外网访问方式对同一个服务器测试，在设置场景过程中，两种方式均相同，其他参数配置一样。唯一不同的是URL。看看结果如何，you can got it! 到底这个问题是怎么解决的，好奇下。
不过我觉得应该是网络问题，你可以通过内网、外网访问方式对同一个服务器测试，在设置场景过程中，两种方式均相同，其他参数配置一样。唯一不同的是URL。看看结果如何，you can got it!
页:
[1]
