以下是我在 Velocity China 2014 做的题为“美团性能分析框架和性能监控平台”演讲的主要内容,现在以图文的形式分享给大家。
今天讲什么?
性能的重要性不言而喻,需要申明的是,我们今天不讲业界最佳性能实践,这些实践已经有很多沉淀,具体可以参考《高性能网站》和《高性能浏览器网络》等书,另外,我们不打算讲性能优化的结果指标,比如页面完全加载时间,首屏时间,结果指标固然重要,是我们工作成果的量化衡量,但是对于做性能优化工作的工程师来说,过程指标对其起到的帮助作用更大。
既然不讲最佳实践,那讲什么呢?我们按最佳实践提供的方法去实践,但是后来遇到了瓶颈,到底遇到了什么瓶颈?我们是如何突破这个瓶颈的?成效如何?这些对在座的各位又有什么借鉴意义呢?
遇到什么瓶颈?
在遇到瓶颈之前,我们做了很多工作,主要包括:
- 简单的数据采集,包括完全加载时间,DomReady 时间,需要注意的是这些都是结果指标;
- 依照“业界最佳实践”快糙猛的做了很多事情:比如异步化,静态化,LazyLoading,BigRender,这些实践效果都还不错;
- 因为只有结果指标数据,这个阶段我们绝大部分决策都是基于别人的经验,甚至拍脑袋,而不是基于应用的实际性能细节数据;
快糙猛的方式注定不是可持续的,很快,我们遇到了瓶颈,具体是什么瓶颈呢?
- 首先,如果把业界最佳实践当成燃料,而性能优化当成驾车远行的话,我们的燃料很快就烧完了,因为大家总结出来的通用的优化手段总是有限的,而我们的目标还没有达到;
- 其次,因为我们只采集了结果指标,只知道整体表现如何,面对异常波动我们显得特别无力,因为显示世界影响性能的因素太多了,对于到底发生什么事情了,我们无从得知;
- 再次,由于对性能缺少内窥,我们无法找到更多的优化点,实际上,我们需要一个类似于显微镜的东西,来看看应用内部还有哪些可优化的地方;
如何突破瓶颈?
面对这些瓶颈,我们需要想办法去突破它。在坐下来想办法之前,我们往后退一步,仔细考虑这样一个问题:我们到底在优化什么东西?是文档的生成速度?页面资源的加载速度?页面的渲染速度?或者说更高大上的用户体验?这些问题想清楚了,才能分析的更彻底。
其实,大多数的性能优化工作都开始于瀑布流图的分析,下面我们就来看看美团项目详情页的瀑布流图:
我们把项目详情页的资源分为以下几部分:
- 主文档,即页面的内容,在拿到主文档之前,浏览器啥都干不了;
- 核心 CSS,和首屏图片,在拿到这些之后,浏览器可以开始渲染了;
- 核心 JS,拿到这些内容之后,页面的交互被丰富,但是也会阻塞;
- 其他内容,比如雪碧图,统计脚本等;
从技术上来讲,我们优化的就是这个瀑布流图的每个环节,那么瀑布流图的背后是什么?
其实就是页面加载过程中各个资源的加载时间分解:从上到下的箭头表示时间轴,从浏览器跳转,缓存检查,再到 DNS、TCP 建连,然后发起主文档请求,再到接收完最后一个字节,再到浏览器开始CSS、JS、图片的下载,最后是页面渲染和交互响应。
根据《高性能网站建设指南》上的数据以及我们的观察,整个页面的加载可以划分为 3 大块:网络时间、后端时间、前端时间,发生在网络和后端的时间占到整体加载时间的 10% 和 20%,而前端资源加载时间占到整体加载时间的 70% ~ 80%。
前端资源加载是否快速对性能影响是最大的,这里面资源的加载顺序,并发数量,都有很多的工作可做:比如,如果你发现 CSS 加载之前的阻塞时间很长,那很可能是资源加载顺序不合理,这必然会导致浏览器渲染延后。
页面的加载时间还能分解的更细么?到目前为止,我们都是站在浏览器的视角,划清了各个环节。浏览器拿到文档之前,是不会做任何事情的,后端响应速度的变动多数时候能引发性能上的蝴蝶效应,我们的突破口就在后端处理时间上:服务器收到请求之后,会经历请求分发、业务逻辑处理、文档生成这三个阶段,在业务逻辑处理阶段,会涉及到和数据库、缓存以及内部服务的通信,拿到所有的数据之后,渲染模板,最后发送给浏览器。
对页面加载过程中涉及到的所有环节进行分解和细化,就形成了我们的分析框架。
如何把控性能?
有了分析框架,那么如何全面的把控网站的性能呢?
基于这个框架,我们通过统计脚本加上必要的数据统计(这里的统计都是过程指标,只反映页面加载过程中某个环节的健康状况),就能获得对整个网站的很多内窥。
具体来说,我们对数据的要求是这样的:整个流程各环节的,多维度(比如分页面、分地理区域、分浏览器)的,实时的(方便我们快速实验)。所有的数据都必须是能够反映整体的统计量。
而对于统计脚本,需要满足两个条件:
- 避免对业务代码的入侵;
- 不影响被测量的页面的性能;
针对第 1 个要求,需要开发独立的统计脚本,避免其与现有的框架耦合,方便移植到其他项目;而针对第 2 个要求,需要在主文档加载完毕之后,再注入统计脚本收集数据,并且尽可能的合并数据请求,减少带宽消耗。
确定了数据统计脚本的约束条件之后,我们从哪里得到这些数据呢?目前使用的主要途径有:
- 主文档加载速度,利用 Navigation Timing API 取得;
- 静态资源加载速度,利用 Resource Timing API 取得;
- 首次渲染速度,IE 下用 msFirstPaint 取得,Chrome 下利用 loadTimes 取得,我们的 Chrome 浏览器用户占比超过 70%;
- 文档生成速度,则是在后端应用内打点来获得;
对于主文档加载速度,我们从宏观到微观的做了这样的分解,从上到下的时间流,右边的时刻标记了每个指标从哪里开始计算到哪里截止,比如,跳转时间 redirect
由 redirectEnd - redirectStart
计算得到,其他的类推:
采集主文档加载速度的具体做法是:
- 在主文档 load 之前提供可缓存数据的接口,方便在统计脚本载入前就可以准备数据;
- 在主文档 load 之后注入数据收集脚本,该脚本加载完成之后会处理所有的数据;
- 利用 Navigation Timing API 收集计算得到上图中的指标;
- 给所有数据打上页面、地理位置、浏览器等标签,方便更细维度的分析;
对于静态资源的加载速度,我们也做了类似的分解和采集:
需要特别提示的是,如果你使用 CDN 的话,需要让 CDN 服务商加上 Timing-Allow-Origin 的响应头,才能拿到静态资源的数据。
而对于主文档生成速度,我们则开发了性能统计的 Library,在框架级别集成后端性能的时间指标。
实际效果如何?
通过上面的各种数据采集,我们拿到了页面加载全流程、全方位、多角度的真实用户数据,有这些数据之后,我们能做什么呢?之前遇到的瓶颈不再是瓶颈,因为我们可以利用这些数据做很多事情,下面举几个实际的例子:
Flush Early 是否有效?
《高性能网站进阶指南》上提到要尽快输出文档的第首字节提高性能,我们很早的时候做了这个事情,但是从数据上看,在页面完全加载时间上的收益不大,做了更细的数据采集之后,我们快速的在线上做了这样的实验:在特定页面把 Flush Early 关掉,结果发现,浏览器接收到第 1 个字节的时间增加了 100+ms,如下图(红色箭头表示变更上线时间点):
而完成文档传输的时间减少了 150+ms,如下图:
表面上看,似乎禁用 Flush Early 效果好些,但是再看看浏览器的首次渲染时间,增加了 300+ms,如下图:
也就是说,有些优化措施,总结果指标上看貌似没啥效果,但是换个角度看效果非常明显。有了全方位的数据,我们能更高效的试错。
发现新的优化点
为了优化文档生成速度,我们一度想到优化函数级别的调用,利用 FaceBook 的 HipHop 为 PHP 加速,通过数据发现,在我们生成文档的时间构成中 30 %是在和缓存交互,这个比例太高了,当优化缓存服务器之后,后端时间大幅下降,缓存占比降到 10% 以下。
另外,美团主站的迭代速度非常快,每天大概 50 次左右的上线,通过数据发现,每次上线都会导致性能的轻微恶化,如果某天上线次数越多,那么性能就好不到哪里去?原因我们合并了大量的 JS 请求,当其中的某个模块在某次迭代中被修改,整个合并的文件需要被重新下载,这就对模块拆分和加载提出了更高的要求。
有了更细节的数据我们能有效发现新的优化点。
性能监控平台
我们不光突破了之前遇到的瓶颈,实际上,我们走的更远,因为我们觉得解决一个问题不如解决一类问题,我们解决问题的思路和工具同样能适用于公司的其他产品线:于是我们在做性能优化的过程中逐步建设起来性能监控平台,目的是为公司的其他产品线和内部系统提供一站式的性能数据收集、计算、存储和展示服务。
目前性能监控平台已经接入 20 余个公司内部系统,能够支持任意指标、任意维度的实时数据查询。该平台为不同的项目提供了性能仪表盘功能,方便快速了解整体的性能状况:
同时还为做性能优化的工程师提供了简单的数据分析功能,方便其以数据驱动的方式的开展性能优化工作:
总结
以上,就是我们做性能优化时遇到的问题,以及解决的办法,下面大概说下,我对这些事情的总结:
- 首先,需要深入的剖析问题,性能分析问题的框架,让很多死角暴露无疑;
- 其次,在性能优化这件事情上,只关注结果指标是不会给你多大帮助的,如果想真的优化,你需要测量过程指标,从过程指标发现更多;
- 再次,解决一个问题比如解决一类问题,解决问题的思路和工具可以沉淀下来,服务更多的团队和同事;
如果想查看演讲的完整视频,可以猛击这里。
至此,本文完!
发现文章有错误、对内容有疑问,都可以关注美团点评技术团队微信公众号(meituantech),在后台给我们留言。我们每周会挑选出一位热心小伙伴,送上一份精美的小礼品。快来扫码关注我们吧!