51Testing软件测试论坛

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

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

楼主: z3z3z3z3
打印 上一主题 下一主题

[原创] 人数增加,吞吐量不变、每秒点击量不变、TPS下降,可否定义为网络瓶颈

[复制链接]

该用户从未签到

21#
发表于 2010-7-20 15:56:25 | 只看该作者
降低并发数,从1加到10,看什么时候出现瓶颈,也就是吞吐率不再上升。
看你在4楼的图就已经可以确定是网络或配置问题了,代码方面的优化可以先不提。
看weblogic线程队列最大值给的多少,队列长度多少,数据库连接池配的多少,是否局域网内测试,客户端到weblogic ping值多少,weblogic ping数据库又是多少,有没有防火墙控制。
回复 支持 反对

使用道具 举报

该用户从未签到

22#
 楼主| 发表于 2010-7-20 16:13:44 | 只看该作者
原帖由 tttrrryyy 于 2010-7-20 15:56 发表
降低并发数,从1加到10,看什么时候出现瓶颈,也就是吞吐率不再上升。
看你在4楼的图就已经可以确定是网络或配置问题了,代码方面的优化可以先不提。
看weblogic线程队列最大值给的多少,队列长度多少,数据库连接 ...


参数方面其实已经有多个Orcale那边的专家来调过,国内的有,新加坡的也有,能调的其实都已经调了,还请了个法国人用代码写了缓存的程序,效果从很烂变为了烂,其实产品本身就有问题,现在想把除产品以外所有因素调到最优,并要拿出证据跟客户解释已经调无可调,让他们接受事实,本身他们选择的产品就这样,不是我们的关系。。。
回复 支持 反对

使用道具 举报

该用户从未签到

23#
发表于 2010-7-20 16:18:13 | 只看该作者
我觉得首先要确定的问题是
最开始只加载50用户
为什么50用户的点击率和吞吐量就会那么高
建议你用50用户多跑一会
拿出稳定的数据分析一下

还有个建议
从10用户开始增加
间隔稍微长一些(保证数据是有效的)
比如每20分钟增加10用户
看看点击率和吞吐量的拐点到底在哪
回复 支持 反对

使用道具 举报

  • TA的每日心情
    擦汗
    2016-10-27 09:19
  • 签到天数: 4 天

    连续签到: 1 天

    [LV.2]测试排长

    24#
    发表于 2010-7-21 09:25:51 | 只看该作者
    来学习
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    25#
    发表于 2010-7-21 17:12:29 | 只看该作者
    很明显的网络瓶颈啊。。。
    你的throughput都超过不了12M,属于百兆范围的。。我以前做的时候,也遇到这情况的,门户网站,图片,js,css太多了,很占带宽的
    建议你,不要去从负载做压力测试了,找2台机器,直接压你们的应用服务器就可以了。效果会有质的飞跃。你的压力发生器要和你们的应用服务器在同一网段哦~~
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    26#
     楼主| 发表于 2010-7-21 17:17:18 | 只看该作者
    原帖由 zl861216 于 2010-7-21 17:12 发表
    很明显的网络瓶颈啊。。。
    你的throughput都超过不了12M,属于百兆范围的。。我以前做的时候,也遇到这情况的,门户网站,图片,js,css太多了,很占带宽的
    建议你,不要去从负载做压力测试了,找2台机器,直接压你 ...


    是指类似直接去机房压?
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    27#
    发表于 2010-7-21 17:39:58 | 只看该作者

    回复 26# 的帖子

    直接压你的APP应用服务器

    比如说,修改脚本中url的地址就可以了

    比如你现在的地址为www.123456.com,需要修改为你们的服务器地址,比如说10.192.22.234,当然需要开发和运维那边来支持你的,也就是说,输入10.192.22.234要能访问到你们的应用,不知道我这样说,你能不能理解。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    28#
     楼主| 发表于 2010-7-21 17:54:26 | 只看该作者

    回复 27# 的帖子

    我现在是用IP直接压的,没有用域名
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    29#
    发表于 2010-7-21 23:04:33 | 只看该作者
    原帖由 zl861216 于 2010-7-21 17:12 发表
    很明显的网络瓶颈啊。。。
    你的throughput都超过不了12M,属于百兆范围的。。我以前做的时候,也遇到这情况的,门户网站,图片,js,css太多了,很占带宽的
    建议你,不要去从负载做压力测试了,找2台机器,直接压你 ...


    如果是这种情况的话,可以只压接口服务,这样就可以排斥是不是门户图片、js的影响了。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    30#
    发表于 2010-7-22 01:36:22 | 只看该作者
    建议楼主还是一步一步的排查
    判断时不时网络瓶颈的手段很多

    发现这里有的人很不低调
    好像什么问题都一眼就看的很明白

    论坛里很多高手都会先提出一些疑点
    然后才慢慢判断的
    性能问题定位是一个逐渐深入的过程
    不要搞得好像明显高出别人似的 别人的问题到你那一眼就有结果了?

    建议楼主还是慢慢来吧
    23楼我提供的方法可以试用一下
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    31#
    发表于 2010-7-22 11:14:03 | 只看该作者

    回复 28# 的帖子

    你要去运维相关人员那去确认一下的,看看你的压力发生器和你的app服务器之间的带宽多大。。
    门户网站我做的多了,信不信由你~!
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    32#
    发表于 2010-7-22 11:16:28 | 只看该作者

    回复 30# 的帖子

    很明显的问题,就不需要复杂化~~~
    既然有过经验,就要拿出来分享~~~
    你没遇到过类似的情况,就不要瞎出主意
    产品快上线了,时间有多紧,你又不是不知道~~!!
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    33#
    发表于 2010-7-22 14:53:00 | 只看该作者
    原帖由 zl861216 于 2010-7-22 11:16 发表
    很明显的问题,就不需要复杂化~~~
    既然有过经验,就要拿出来分享~~~
    你没遇到过类似的情况,就不要瞎出主意
    产品快上线了,时间有多紧,你又不是不知道~~!!


    看来在你眼里什么问题都很简单了
    你怎么知道我没遇到过类似的问题

    性能测试需要从很多方面去定位问题
    怎么在你这看两个图就能定位了
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    34#
    发表于 2010-7-22 19:43:05 | 只看该作者

    回复 9# 的帖子

    我觉得您的最后那两幅图能说明您所测的web网站的性能测试存在问题,或者存在网络延时等情况。
    因为当用户数达到稳定状态时,TPS和平均响应时间波动实在是太大了,您觉得呢?
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    35#
    发表于 2010-7-22 22:30:22 | 只看该作者
    原帖由 zl861216 于 2010-7-22 11:16 发表
    很明显的问题,就不需要复杂化~~~
    既然有过经验,就要拿出来分享~~~
    你没遇到过类似的情况,就不要瞎出主意
    产品快上线了,时间有多紧,你又不是不知道~~!!


    典型的半瓶子咣当型选手
    就你一个人懂性能测试被

    估计也就是在个小公司做测试的
    你要真是在百度搜狐淘宝的也行 算你牛逼
    要不就别装大了
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    36#
    发表于 2010-7-23 10:12:23 | 只看该作者
    原帖由 shigui3615 于 2010-7-22 19:43 发表
    我觉得您的最后那两幅图能说明您所测的web网站的性能测试存在问题,或者存在网络延时等情况。
    因为当用户数达到稳定状态时,TPS和平均响应时间波动实在是太大了,您觉得呢?


    请详解,你的意思是应该平稳在高位,不应该出现向下的波动???
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    37#
    发表于 2010-7-23 17:11:03 | 只看该作者
    原帖由 z3z3z3z3 于 2010-7-20 15:37 发表
    我怎么看服务器端的带宽?
    按照公式:1.5M*8*400/5=960M/s,服务器千兆带宽应该够吧


    诶呦呦,960M/S  厉害哦~

    百兆的路由哦,理论速度是12.5MB/S吧  不信你可以用飞鸽传文件算算 超过这个是不可能滴
    千兆带宽哦,理论熟读是125MB/S 不信...
    较好的服务器硬盘算你6Gb/S,理论速度是800MB/S

    换千兆的路由没的效果,说明服务器网卡是百兆滴~

    外话:人数增加,吞吐量不变,那是不可能滴
          不变的可能是速率,总量是绝对要上去滴,响应时间是绝对要慢下来滴,如果是这样网络就是瓶颈滴
          当然,万事不靠谱,还得具体问题具体分析滴,各个场景不同也不能一概而论滴

    我们平时在算速率时用的是Bit,在标注一个硬件有多快时候也是用Bit
    但体现在直观层面上,我们更希望看到的是Byte,就像很多流量小工具一样都用这个,只不过换成KB的给你显示出来,也就有了常有的KB/S之类的
    Loadrunner上用的是Byte
    还是算清楚来比较好,一差差好多的

    大家弄个360流量监控之类的,你看看,在并发要过的时候,你的流量达到多少了?直观明了啊~还每个虚拟用户进程都给你标好哈哈~
    别忘了服务器上也搞个
    记得关网盾实时保护之类的

    [ 本帖最后由 twinsczl 于 2010-7-23 17:13 编辑 ]
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    38#
     楼主| 发表于 2010-7-23 17:49:27 | 只看该作者

    回复 37# 的帖子

    请教了,1.5M(bytes) * 8 * 400(人) / 5(s)=960M(bits/s) 有问题吗?

    关于带宽,客户明确说明了服务器端是千兆的
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    39#
    发表于 2010-7-24 11:47:08 | 只看该作者
    原帖由 cen0225 于 2010-7-23 10:12 发表


    请详解,你的意思是应该平稳在高位,不应该出现向下的波动???


    网上看到的观点:
        事务通过数的意思是每个特定时间间隔内通过的事务数,如果随着场景执行时间的推延,通
    过事务数曲线应该是平缓的,如果突然上升,则可能是服务不稳定,或者网络因素导致的,
    如果持续下降,则表示服务的处理能力在下降,此时可以查看服务器段是否有进程堵塞,或
    者服务器的连接数不够,也可能是网络带宽不够.


        平均事务响应时间在整个测试过程中是一个很重要的参考指标,他能清晰的反映出场景
    执行过程中,每个事务的执行时长,整个业务中哪个操作最耗时等等。场景执行结束后,可
    以根据这个图表分析出在一定响应时间要求下,系统可支持的并发数,假如我们要求在查询
    的时候要求这个返回结果的时候不超过5 秒,那么可以在场景中找到对应的SubQue 事务在
    处理时间为5 秒左右的时间点,再从Running Vuser 图中找到对应的时间点,查看对应的并
    发用户数。同样,在整个执行过程中,当并发数达到一定数值后,平均事务响应时间曲线应
    该是平缓的,如果出现突然升高或者降低的情况,则表示系统存在异常,这样我们可以找到
    这个时间点去查看服务器端的运行日志,查找原因.
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    40#
    发表于 2010-7-26 09:17:38 | 只看该作者

    回复 38# 的帖子

    找个和生产环境同一个网段的负载机,压一下,就知道了嘛~!!
    如果不出意外的话,你们的网络流量会飙升上去,你的hits per second会高达3000以上的,这时,有可能会出现LoadRunner自生的链接与释放问题,去网上搜一下,去注册表里改个参数就可以了,当然,如何没有出现问题,就更好了~~~~~
    同时你的throughput也会飙升上去的,你的服务器CPU利用率也会上去的。
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

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

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

    GMT+8, 2024-11-7 05:24 , Processed in 0.079009 second(s), 21 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

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