共勉
"诸君离学校而去了。在社会上立身的困难,恐怕比在学校里求学还要加甚。若非立志奋斗,则以前所受的教育,反足以增加人生的苦恼,或转为堕落的工具。这是诸君所当特别注意的。事业的成功,须经过长时间的辛苦艰难——成功的代价,走过了许多荆棘的路,方才能寻获康庄大道。立志是砍荆棘斧斤,奋斗是劳力。万不可希望以最少的劳力,获最大的成功。" -- 蒋梦麟
Knight's Blog
滴滴海浪技术主管, 前百度资深研发工程师,现居上海。 擅长于大规模的系统平台服务架构。在

- 亿级别搜索平台(sov5.cn)
- 大规模分布式爬虫
- 中间件架设(disconf,CanalX)
- 广告平台(百度联盟广告)
- 租车平台(滴滴租车)
- 语言招聘平台(51tra.com)
- 内容平台(100weidu.com)
- 社区平台(python88.com)
- 资源下载平台(misou.com)
- 计算机图形图像技术(一篇一作)
- 机器学习(一篇一作)

等领域具有颇有经验。
联系方式: knightliao AT gmail.com
联系
Knight's Blog » 工作

处理 waiting ttfb too long 的一次经历

2016-11-15 13:36

近几天一直有人反应我的网站速度时好时坏,我一直不在意,觉得应该不会是服务的问题,是网络的问题好嘛!

今天试了一下,发现确实是这样的,chrome下反应某个URL时,出现惊人的 waiting ttfb too long 的问题。(时间长达20s)

在网上查了一下,http://fex.baidu.com/blog/2015/01/chrome-stalled-problem-resolving-process/ waiting ttfb是指:等待响应的时间,具体来说是等待返回首个字节的时间。包含了与服务器之间一个来回响应的时间和等待首个字节被返回的时间。

这就意味着对于该请求而言,服务器响应非常慢。

然后我看了一下服务器日志,发现响应都是几百ms之内,没啥问题。这里就比较奇怪了,后端没有问题啊!!!

所以,现在的问题就归结为 浏览器请求速度很慢,但是后台正确响应的问题。

然后我查了nginx日志,发现很多 nginx errors “recv() failed (104: Connection reset by peer) while reading response header from upstream” 的错误。google了一下,http://serverfault.com/questions/543999/nginx-errors-recv-failed-104-connection-reset-by-peer-while-reading-respon 这里指明很可能是有服务出现拒绝访问502了。

到这里,我基本上可以确定问题是:后台有若干台服务,挂了几台,存活着几台,因此,如果刚好被好的服务器响应时就好,如果被差的服务器响应时就会出现几十秒的延迟(nginx会在超时后自动转到好的服务器上),上体表现就是服务速度时好时坏。

查了一下所有服务的日志,发现有几台服务器的日志在几天前就不更新了。。这里也确认了我的判断。。

至于为啥服务器突然死掉的问题,还在排查中。。

2182 次点击