对美团的网站性能分析及性能监控方案的剖析

性能的重要性是不言而喻的。需要注意的是，美团今天并没有谈论行业中最好的性能实践。这些实践有很多沉淀。详情请参考《高性能网站》、《高性能浏览器网络》等书籍。此外，美团不打算谈论性能优化的结果指标，如页面完全加载时间和第一个屏幕时间。结果指标很重要，这是对美团工作成果的量化衡量，但对于做性能优化的工程师来说，过程指标对其起着更大的帮助作用。既然不谈最好的练习，说什么？既然我们不谈论最好的实践，我们该说什么？美团按照最佳实践提供的方法进行实践，但后来遇到了瓶颈。瓶颈是什么？美团是如何突破瓶颈的？成效如何？这些对在座的各位有什么借鉴意义？遇到什么瓶颈？在遇到瓶颈之前，美团做了很多工作，主要包括：简单的数据收集，包括完全加载时间和Domready时间。需要注意的是，这些都是结果指标；根据“行业最佳实践”，我做了很多事情：如异步化和静态化，LazyLoading，BigRender，所有这些实际效果都很好，因为只有结果指标数据，在这个阶段，美团的大部分决定都是基于他人的经验，甚至是拍头，而不是基于应用程序的实际性能细节；快速粗糙的方式注定不可持续，很快，美团遇到了瓶颈，具体的瓶颈是什么？首先，如果行业的最佳实践被视为燃料，而性能优化被视为长途驾驶，美团的燃料很快就会燃烧，因为总结的一般优化手段总是有限的，而美团的目标还没有实现；其次，因为美团只收集结果指标，只知道整体表现，面对异常波动，美团特别弱，因为有太多的因素显示世界影响性能，发生了什么，美团无法知道；第三，由于缺乏性能内窥镜，美团找不到更多的优化点。事实上，美团需要一些类似显微镜的东西来看看应用程序中有哪些优化点；如何突破瓶颈？面对这些瓶颈，美团需要想办法突破。面对这些瓶颈，美团需要想办法突破。在坐下来想办法之前，美团退后一步，仔细考虑美团在优化什么？是文档的生成速度吗？页面资源的加载速度？页面渲染速度？还是用户体验更高？只有想清楚这些问题，才能更彻底地分析。事实上，大多数性能优化工作都是从瀑布流图的分析开始的。接下来，美团将查看美团项目详细信息页面的瀑布流图：美团将项目详细信息页面的资源分为以下几个部分：主文档，即页面内容，浏览器在获得主文档之前无能为力；核心CSS和第一个屏幕图片可以在获得这些后开始渲染；核心JS在获得这些内容后丰富了页面的互动，但也会被堵塞；其他内容，如雪碧图、统计脚本等；从技术上讲，美团优化了瀑布流图的每一个环节。瀑布流图背后是什么？事实上，页面加载过程中各种资源的加载时间分解：从上到下箭头表示时间轴，从浏览器跳转、缓存检查到DNS、TCP建连，然后发起主文档请求，然后接收最后一个字节，再到浏览器开始CSS、JS、下载图片，最后是页面渲染和交互响应。根据《高性能网站建设指南》上的数据和美团的观察，整个页面的加载可分为三个部分：网络时间、后端时间和前端时间。发生在网络和后端的时间占总加载时间的10%和20%，而前端资源的加载时间占总加载时间的70%~80%。前端资源加载是否快速对性能影响最大。资源的加载顺序和并发数量有很多工作要做：例如，如果您发现CSS加载前的阻塞时间很长，很可能资源加载顺序不合理，这将不可避免地导致浏览器渲染延迟。前端资源加载是否快速对性能影响最大。有很多工作可以做资源的加载顺序和并发数量：例如，如果您发现CSS加载前的阻塞时间很长，很可能资源加载顺序不合理，这将不可避免地导致浏览器渲染延迟。页面的加载时间能更详细地分解吗？到目前为止，美团一直站在浏览器的角度，划清各个环节。浏览器在获得文档之前不会做任何事情。大多数时候，后端响应速度的变化会导致性能蝴蝶效应。美团的突破在于后端处理时间：服务器收到请求后，将经历三个阶段：请求分发、业务逻辑处理和文档生成。在业务逻辑处理阶段，它将涉及与数据库、缓存和内部服务的通信。获取所有数据后，渲染模板，最后发送给浏览器。分解和细化页面加载过程中涉及的所有环节，形成美团的分析框架。分解和细化页面加载过程中涉及的所有环节，形成美团的分析框架。如何控制性能？有了分析框架，如何全面控制网站的性能？基于此框架，美团可以通过统计脚本和必要的数据统计（这里的统计是过程指标，只反映页面加载过程中某个环节的健康状况）获得整个网站的大量内窥镜。具体来说，美团对数据的要求如下：整个过程、多维度（如页面、地理区域、浏览器）、实时（方便美团快速实验）。所有数据都必须能够反映整体统计。对于统计脚本，需要满足两个条件：避免入侵业务代码；不影响测量页面的性能；对于第一个要求，需要开发独立的统计脚本，避免与现有框架耦合，方便移植到其他项目；对于第二个要求，需要在主文档加载后注入统计脚本收集数据，并尽可能合并数据请求，以减少带宽消耗。在确定了数据统计脚本的约束后，美团从哪里获得了这些数据？目前使用的主要方式有:主文档加载速度，通过NavigationtimingAPI获得；静态资源加载速度，通过ResourcetimingAPI获得；第一次渲染速度，IE通过msfirstaint获得，Chrome通过loadtimes获得，美团Chrome浏览器用户占70%以上。；文档生成速度，它是在后端应用程序中获得的；对于主文档的加载速度，美团从宏观到微观进行了这样的分解。从上到下的时间流，右边的时刻标记了每个指标从哪里开始计算到哪里结束。例如，跳转时间redirect由redirectend-redirectstart计算，其他类比：收集主文档加载速度的具体方法是在主文档load之前提供缓存数据界面，以便在统计脚本输入之前准备数据；在主文档load之后注入数据收集脚本，加载完成后，脚本将处理所有数据；使用NavigationTimingAPI收集和计算以获取上图中的指标；在页面、地理位置、浏览器和其他标签上标记所有数据，以便于更详细的维度分析；美团还对静态资源的加载速度进行了类似的分解和收集：如果您使用CDN，需要特别提示，CDN服务提供商需要添加Timing-Allow-只有Origin的响应头才能获得静态资源数据。至于主文档的生成速度，美团开发了Library的性能统计，将后端性能的时间指标集成到框架级别。至于主文档的生成速度，美团开发了Library的性能统计，将后端性能的时间指标集成到框架级别。实际效果如何？通过以上数据收集，美团获得了页面加载全过程、全方位、多角度的真实用户数据。有了这些数据，美团能做什么？之前遇到的瓶颈不再是瓶颈，因为美团可以利用这些数据做很多事情。以下是Flushearly是否有效的实际例子？“高性能网站高级指南”提到尽快输出文档第一字节提高性能，美团很早就这样做了，但从数据来看，页面完全加载时间收入不大，做更详细的数据收集，美团快速在线实验：在特定页面关闭Flushearly，结果发现浏览器收到第一个字节时间增加了100 ms，如下图所示(红色箭头表示更改上线时间点)：文档传输的完成时间减少了150 ms，如下图所示：表面上看，禁用Flushearly似乎更有效，但再看浏览器的首次渲染时间，增加了300 ms，下图:也就是说，一些优化措施在总结果指标上似乎没有效果，但从另一个角度来看效果非常明显。有了全方位的数据，美团可以更有效地尝试和犯错误。有了全方位的数据，美团可以更有效地尝试和犯错误。为了优化文档生成速度，美团曾经考虑调用优化函数级别，并利用FaceBookHipHop加速PHP。通过数据发现，30%的美团生成文档时间构成与缓存交互，这太高了。优化缓存服务器后，后端时间大幅下降，缓存比例降至10%以下。此外，美团主站的迭代速度非常快，每天上线约50次。通过数据发现，每次上线都会导致性能轻微恶化。如果有一天上线次数越多，性能就不会好多少。原因是美团合并了大量JS请求。当其中一个模块在迭代中被修改时，需要重新下载整个合并文件，这对模块的拆卸和加载提出了更高的要求。有了更详细的数据，美团可以有效地找到新的优化点。性能监控平台美团不仅突破了瓶颈，事实上，美团更进一步，因为美团认为解决问题不如解决问题，美团解决问题的想法和工具也可以适用于其他产品线：所以美团在性能优化过程中逐步建立性能监控平台，目的是为其他产品线和内部系统提供一站式的性能数据收集、计算、存储和显示服务。目前，性能监控平台已接入20多个公司内部系统，可支持任何指标、任何维度的实时数据查询。该平台为不同的项目提供性能仪表板功能，方便快速了解整体性能：同时为性能优化工程师提供简单的数据分析功能，方便数据驱动性能优化工作：总结以上，是美团性能优化问题和解决方案，以下可能是我对这些事情的总结：首先，需要深入分析问题，性能分析问题的框架，毫无疑问，暴露许多死角；其次，在性能优化方面，只关注结果指标不会对你有多大帮助。如果你想真正优化，你需要测量过程指标，从过程指标中找到更多；第三，解决一个问题，如解决一类问题，可以沉淀解决问题的想法和工具，为更多的团队和同事服务；