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

性能的重要性是不言而喻的。需要注意的是，美团今天并没有谈论行业中最好的性能实践。这些实践有很多沉淀。详情请参考《高性能网站》、《高性能浏览器网络》等书籍。此外，美团不打算谈论性能优化的结果指标，如页面完全加载时间和第一个屏幕时间。结果指标很重要，这是对美团工作成果的量化衡量，但对于做性能优化的工程师来说，过程指标对其起着更大的帮助作用。既然不谈最好的练习，说什么？既然我们不谈论最好的实践，我们该说什么？美团按照最佳实践提供的方法进行实践，但后来遇到了瓶颈。瓶颈是什么？美团是如何突破瓶颈的？成效如何？这些对在座的各位有什么借鉴意义？遇到什么瓶颈？在遇到瓶颈之前，美团做了很多工作，主要包括：简单的数据收集，包括完全加载时间和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多个公司内部系统，可支持任何指标、任何维度的实时数据查询。该平台为不同的项目提供性能仪表板功能，方便快速了解整体性能：同时为性能优化工程师提供简单的数据分析功能，方便数据驱动性能优化工作：总结以上，是美团性能优化问题和解决方案，以下可能是我对这些事情的总结：首先，需要深入分析问题，性能分析问题的框架，毫无疑问，暴露许多死角；其次，在性能优化方面，只*结果指标不会对你有多大帮助。如果你想真正优化，你需要测量过程指标，从过程指标中找到更多；第三，解决一个问题，如解决一类问题，可以沉淀解决问题的想法和工具，为更多的团队和同事服务；

以上就是关于对美团的网站性能分析及性能监控方案的剖析的相关介绍，更多对美团的网站性能分析及性能监控方案的剖析相关内容可以咨询我们或者浏览页面上的推荐内容。我们将让你对对美团的网站性能分析及性能监控方案的剖析有更深的了解和认识。