51Testing软件测试论坛

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

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 5666|回复: 29
打印 上一主题 下一主题

[原创] LR结果分析,求高手帮助

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2010-8-7 09:52:56 | 只看该作者 回帖奖励 |正序浏览 |阅读模式
我对系统做了个并发操作,100vusers;
得到测试结果,吞吐率、响应时间、系统资源等,但是综合分析下比较困难,不知道怎么入手,请高手指教!

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有帐号?(注-册)加入51Testing

x
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

该用户从未签到

30#
发表于 2011-3-28 15:29:57 | 只看该作者
最近也遇到类似的情况。。。郁闷ing。。。
回复 支持 反对

使用道具 举报

该用户从未签到

29#
 楼主| 发表于 2010-8-17 10:05:23 | 只看该作者
原帖由 jj_ljw 于 2010-8-17 09:42 发表
搞好没,来个结果啊

我需要大家的指导啊,学习ing
回复 支持 反对

使用道具 举报

该用户从未签到

28#
发表于 2010-8-17 10:04:43 | 只看该作者
是不是你把脚本全都放在init里面了,action里面是空的,无线循环当然没有流量
回复 支持 反对

使用道具 举报

该用户从未签到

27#
发表于 2010-8-17 09:42:20 | 只看该作者
搞好没,来个结果啊
回复 支持 反对

使用道具 举报

该用户从未签到

26#
 楼主| 发表于 2010-8-17 09:04:50 | 只看该作者
原帖由 ganlan 于 2010-8-17 08:52 发表
给你个思路:
1、首先,在没确定系统情况前建议并发数平稳上升,例如1Vser/3s,5s 等;
2、结合Vuser 查看TPS,throughput 走势,因为系统在稳定情况下,这两个值是稳定的,当Vuser到达一定程度,这两个值是不会再上 ...

嗯 谢谢
回复 支持 反对

使用道具 举报

该用户从未签到

25#
发表于 2010-8-17 08:52:49 | 只看该作者
给你个思路:
1、首先,在没确定系统情况前建议并发数平稳上升,例如1Vser/3s,5s 等;
2、结合Vuser 查看TPS,throughput 走势,因为系统在稳定情况下,这两个值是稳定的,当Vuser到达一定程度,这两个值是不会再上升了,此时需要观看Response Time。
3、系统资源主要是观看是否出现瓶颈,不同的系统资源要求不一样。
回复 支持 反对

使用道具 举报

该用户从未签到

24#
 楼主| 发表于 2010-8-16 11:20:05 | 只看该作者
原帖由 hdice 于 2010-8-16 11:13 发表
首先楼主得说一下程序是怎样部署的,是(web---api---db???)

资源图上只有1个机器的cpu,是不是db的cpu没有加上?
我看hits per second升高后突然降低,DB是不是压力太大,DB服务器压力一直在高位,无法响应;也 ...

我在论坛上的另外一个帖子:http://bbs.51testing.com/thread-283369-1-1.html,一台服务器装有两台虚拟机:Win2000(部署应用) 和 Linux(部署DB)

这个帖子做了和这边相似的压力测试,请高手们去帮我看看测试结果,帮忙分析一下,不甚感激
回复 支持 反对

使用道具 举报

该用户从未签到

23#
 楼主| 发表于 2010-8-16 11:16:02 | 只看该作者
原帖由 hdice 于 2010-8-16 11:13 发表
首先楼主得说一下程序是怎样部署的,是(web---api---db???)

资源图上只有1个机器的cpu,是不是db的cpu没有加上?
我看hits per second升高后突然降低,DB是不是压力太大,DB服务器压力一直在高位,无法响应;也 ...

我这个部署时有点问题,一台服务器,应用在服务器上。服务器上还有个虚拟机。里面是DB
回复 支持 反对

使用道具 举报

  • TA的每日心情
    难过
    2017-7-25 17:19
  • 签到天数: 2 天

    连续签到: 1 天

    [LV.1]测试小兵

    22#
    发表于 2010-8-16 11:13:21 | 只看该作者
    首先楼主得说一下程序是怎样部署的,是(web---api---db???)

    资源图上只有1个机器的cpu,是不是db的cpu没有加上?
    我看hits per second升高后突然降低,DB是不是压力太大,DB服务器压力一直在高位,无法响应;也可能大量的数据库查询造成死锁(程序原因),猜测。

    多说点废话,,,,
    如果把机器的cpu压到100%了,压力肯定是过高了,这样的压力没啥意义,也得不到参考价值的结果。
    性能测试前期准备很重要,生产环境的实际压力是多少、有没有负载均衡、生产环境和测试环境机器的硬件软件比较、生产环境和测试环境部署是否一致(比如,生产环境web--api--db是部署到不同的机器上,而测试环境web和api部署到一台机器,db部署到一台机器等等)、我们测试用的参数是与实际的数据有多大的差异。。。。。。。。等等等等,好多因素影响到测试结果。我们尽量多的考虑各种因素用正确的参数给服务合理的压力,才能完成一次成功的性能测试任务。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    21#
     楼主| 发表于 2010-8-10 17:49:50 | 只看该作者
    原帖由 kuangquanshui 于 2010-8-10 17:30 发表
    响应时间是不是没去掉思考时间

    响应时间和思考时间有什么内在的联系,请指教,谢谢
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    20#
     楼主| 发表于 2010-8-10 17:46:30 | 只看该作者
    原帖由 kuangquanshui 于 2010-8-10 17:30 发表
    响应时间是不是没去掉思考时间

    我登陆脚本里是有思考时间的
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    19#
    发表于 2010-8-10 17:30:59 | 只看该作者
    响应时间是不是没去掉思考时间
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    18#
    发表于 2010-8-10 17:18:16 | 只看该作者
    持续关注
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    17#
     楼主| 发表于 2010-8-9 13:40:56 | 只看该作者
    原帖由 杀手太冷 于 2010-8-9 11:41 发表
    响应时间有点吓人的,才100VU,平均:21.17,90%都是41

    应用部署在Tomcat 中,数据库Oracle 放在虚拟机中,请指教!谢谢
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    16#
    发表于 2010-8-9 11:44:22 | 只看该作者
    8分钟的时候,VU该处于加载中,而且也没有返回错误,应该不是服务器挂了~~~
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    15#
    发表于 2010-8-9 11:41:19 | 只看该作者
    响应时间有点吓人的,才100VU,平均:21.17,90%都是41
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    14#
     楼主| 发表于 2010-8-9 11:26:07 | 只看该作者
    原帖由 akui 于 2010-8-9 11:23 发表
    这个就不清楚了,可能是6楼云大侠所说的原因吧!

    系统正常,链接也正常
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    13#
    发表于 2010-8-9 11:23:17 | 只看该作者

    回复 11# 的帖子

    这个就不清楚了,可能是6楼云大侠所说的原因吧!
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    12#
    发表于 2010-8-9 11:03:02 | 只看该作者
    为撒子8分钟的时候。会出现这种情况呢?
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

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

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

    GMT+8, 2024-11-10 15:24 , Processed in 0.089352 second(s), 29 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

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