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