瓶颈分析：web page download Time，为何都是First Buffer占用呢？

樱qq · 发表于 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几乎可以忽略不计，这又说明什么问题呢？

shigejinian1 · 发表于 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进程数的调整。

樱qq · 发表于 2011-9-15 12:56:38

嗯嗯，shigejinian1说的，我明白啦哈

樱qq · 发表于 2011-9-15 13:04:15

按2楼的说法，经过与开发人员一块排查发现,MONGO数据库那边监控到连接数已经达到上限20000个了

发现问题所在了先。。后面再看看还有没其它问题。。哈。。谢谢啦

msnshow · 发表于 2011-9-15 13:50:13

90%以上的时间花费在Server Time上面

这个很正常，你的服务器忙不过来了

shigejinian1 · 发表于 2011-9-15 14:44:50

		自动登录	找回密码
密码			(注-册)加入51Testing

[原创] 瓶颈分析：web page download Time，为何都是First Buffer占用呢？

相关帖子

站长推荐 /1