51Testing软件测试论坛

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

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 2714|回复: 5
打印 上一主题 下一主题

[原创] 瓶颈分析:web page download Time,为何都是First Buffer占用呢?

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2011-9-13 22:12:43 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
本帖最后由 樱qq 于 2011-9-13 22:13 编辑

公司要求测试一个接口,并发400个用户,之后发现TPS极低=5
CPU和内存均暴涨到90%以上,事务平均响应时间在80S以上,
性能极差!

现在准备分析一下哪方面引起,看Web page download Time图发现

(1)   99%的时间占用花在First Buffer上面,而其它的如:Connectiong、DNS Resolution
           Receive、Client等均未占用时间
           这很奇怪,说明什么问题呢?

(2) 进一步查看Time to First Buffer发现,90%以上的时间花费在Server Time上面
           NetWork Time几乎可以忽略不计,这又说明什么问题呢?
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

该用户从未签到

2#
发表于 2011-9-14 15:03:08 | 只看该作者
给LZ提个参考意见
你这个CPU和内存监控的得是web服务器 就是部署程序的机器。
1、尝试查看出现这类情况时候数据库process,看看是否是当时进程到达了所设置的进程数上限。如果是则调整数据库进程数上限再测试
2、尝试查看程序连接池设置的最大连接数,如果程序设置的最大连接数上限很小,调整上限在测试看看
进程排队是合理现象,但是需要在当前硬件环境下,将其控制在可接受范围内。
如果经过调整过数据库进程上限和最大连接数,仍然无法解决问题,找到你的脚本
假设你的脚本顺序是(其中a,b,c代表的是程序模块)
web_submit_data(a);
web_submit_data(b);
web_submit_data(c);
分别找出他们在analysis中的响应时间,按照顺序从第一个响应时间长的系统模块开始调优,就是调整程序的算法或者SQL。假如响应时间 b>c>a,那么就先调整b,之后再测试。因为有可能是由于b排队导致c无法正常执行所以才响应时间漫长的。
以上仅供参考,没有用过mongodb,数据库进程数我参考的是oracle进程数的调整。
回复 支持 反对

使用道具 举报

该用户从未签到

3#
 楼主| 发表于 2011-9-15 12:56:38 | 只看该作者
嗯嗯,shigejinian1说的,我明白啦哈
回复 支持 反对

使用道具 举报

该用户从未签到

4#
 楼主| 发表于 2011-9-15 13:04:15 | 只看该作者
按2楼的说法,经过与开发人员一块排查发现,MONGO数据库那边监控到连接数已经达到上限20000个了

发现问题所在了先。。后面再看看还有没其它问题。。哈。。谢谢啦
回复 支持 反对

使用道具 举报

  • TA的每日心情
    奋斗
    2022-5-8 19:23
  • 签到天数: 137 天

    连续签到: 1 天

    [LV.7]测试师长

    5#
    发表于 2011-9-15 13:50:13 | 只看该作者
    90%以上的时间花费在Server Time上面

    这个很正常,你的服务器忙不过来了
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    6#
    发表于 2011-9-15 14:44:50 | 只看该作者
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

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

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

    GMT+8, 2024-11-16 07:46 , Processed in 0.066220 second(s), 25 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

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