美团性能分析框架和性能监控平台-k6k4.com

以下是我在 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，如下图（红色箭头表示变更上线时间点）：