记 一次线上问题的排查和解决

场景还原 2019/12/28晚19:05左右,突然被拉进微信群。放出一段微信聊天记录,公司(国内某知名的互联网金融公司)高管使用app时发现公司app中活动推广页面打开缓慢,20+s才打开,产品,市场部老大被质问。此时问题来到了我们开发组内。 收到问题后,组长和其他运营人员等其他人员,用手机访问同一个活动推广页,都可以1.5s内打开页面。 问题设想 先简单介绍下项目结构和背景。 该项目是一个配置项目,姑且称之为"活动配置项目",该项目分为一个配置平台和一个H5展示平台,在配置平台可以配置H5页面的展示图片,按钮定位,轮播图等等,通过生成一个结构化的json文件,上传到cdn。H5展示平台通过ajax获取cdn的json文件,同时解析JSon文件,并渲染出对应的页面。同时需要对接公司三大平台app,所有内部有很多和app进行交互的JS文件,还有各平台特有的统计JS。由于公司内三大平台基本相互独立,在技术层面没有对native的一些能力做统一,导致一些JS的功能存在冗余,但是又不得不引入。 "活动配置项目"配置生成的主要有两部分内容,第一部分:描述的配置JSon文件,第二部分:项目中用到的图片。两者均存放于cdn中。 由上场景还原可猜想,页面业务逻辑应该不会有问题。做以下猜想:并从上往下优先级排查 静态资源在某些特定网络下加载缓慢导致,包括html,JS,配置的JSon文件,以及图片资源。 检查前端页面代码,看是否是JS获取缓慢(阻塞)而导致页面无法进入业务中。 排查方向 第一点排查:对公司所用到的所有cdn进行测试,未发现明显异常。在cdn回源测试中,发现个别cdn站点出现504异常,后经排查,应该不是由于cdn导致缓慢。 第二点排查:服务器使用情况排查,发现当前活动部署与一台公用iis服务中,当前服务器中部署了多个服务,可能存在某些时刻服务资源争抢导致服务响应时间变长的情况。 第三点排查:发现H5展示平台对JS的引入都放在html的head或body的首部进行加载,同时,通过chromeDev tool工具,发现一共引入了20左右个JS文件。 问题定位 因为无法重现公司老总的问题,但是既然问题出现了,还是要想尽办法解决问题,进行优化的。 前端中JS在未开启async,defer时,JS的载入执行都是依照从上往下执行的。所有党20个JS同时放在首部,只需要一个JS载入缓慢,则可以导致后续的业务无法执行。这一点是必须要解决的。 同时另一点,当有多个JS同时放在首部,每个JS的下载都需要和服务器建立连接,在Chrome浏览器中建立连接的并发数在7个左右,所有后续的资源都需要等待。同时建立多个连接,都需要进行TCP的建立,握手,SSL的建立,在网络层面是很大开销。 问题定位一:对此给出策略是降低连接的建立,即减少JS的网络请求 对于是否需要把所有的JS放在首部,主要取决于业务是否需要依赖这些js。因此对所有js进行了梳理,把业务强依赖相关的js放在首部加载。而对于业务弱相关的js放在尾部引用。这里弱相关的有两种类型,第一种是类似于统计功能的,即使js载入失败,也不会导致业务页面无法出现。第二种是只会在页面的点击事件等才会用到的js。基于第二种的,还是会存在js没有加载成功,此时点击事件中业务逻辑无法完成。 问题定位二:理清强依赖js和弱依赖js,分开进行首尾分别加载 文件的大小在文件传输时间中占有很大的因素,所以对文件进行特定的处理,会有比较大影响 问题定位三:对未进行压缩的js进行压缩处理。同时在服务器开启gizp压缩,减少网络传输的字节大小 基于定位的三点问题,得到的整体优化方案是:优化cdn回源配置,将活动迁移到单独的服务器上。在前端层面理清强依赖的js放在首部,弱依赖的js放在尾部,同时对首部的js进行合并压缩处理,对尾部的js进行压缩合并出来。并且服务器开启gzip压缩 修正问题 基本确定了优化方向,剩下就是如何实现优化方案了。 厘清页面渲染依赖关系,将强制依赖放在首部,非依赖或弱依赖放在尾部。 项目前期并没有使用任何构建工具,并没有对一些js进行压缩。优化的方案是使用gulp对前置依赖js进行合并并压缩,对后置弱依赖或者非依赖的js分开打包,在引入。 保证页面渲染为第一要务,剩下的其他sdk初始化等操作都等最后再进行。 测试性能报告 修改前 修改前在ChromeDev Tool工具下网络的连接传输情况。如下,从图上可以看到,页面载入了20个js,从这张图反馈出来的信息除了载入js的多少,在waterfall一栏中,可以看到诸多的黄色和紫色,期表示的就是网络连接必要的,黄色为建立连接的时间,紫色则是SSL建立连接的时间。而造成这个问题最主要的原因猜测是由于Chrome建立连接的并发数只能在7个左右,多余的资源需要下载,这需要排队等待,并且可能导致连接断开,无法复用连接,在这里就已经花费了较多的时间。 修改前.png 修改后 修改后,js的资源从20个变为10个,将前置依赖打包成vendor.js,将app的弱依赖或者是非依赖打包成app.js。通过减少js的请求,以减低http连接的建立和ssl的建立,减少服务器的io操作。 从ChromeDev Tool中的waterfall已经不见了黄色和紫色,证明网络方面表现良好。 修改后@2x.png 总结 凡是免不了要总结一下 前端的表现性能直接影响着用户的体验,毕竟是里用户最近的,前端工程师更应该站用户的角度去理解产品。话说回来,前端优化抛开前端代码层面的实现因素,影响最大的莫过于网络的因素。而网络的因素是复杂的,资源的访问取决于你的网络架构是怎么样的。 从最简单的:客户端发起请求 -> (建立连接)-> 资源服务器返回资源 -> 客户端执行并渲染。 但是,为了提升服务的可用性,网络架构会使用代理服务器 使用了代理服务: 客户端发起请求 -> (建立连接) -> 代理服务器检查资源是否有效 -> (有效) -> 资源返回 -> 客户端执行并渲染 客户端发起请求 -> (建立连接) -> 代理服务器检查资源是否有效 -> (无效) -> 访问资源服务器 -> 资源返回 -> 代理服务器缓存(继续响应客户端) -> 客户端执行并渲染 又但是,如果某些资源是存放cdn中,则资源又需要访问cdn和回源等问题 客户端发起请求 -> (寻找最近节点的cdn服务器,建立连接) -> cdn是否存在资源 -> (存在) -> 资源返回 -> 客户端执行并渲染 客户端发起请求 -> (寻找最近节点的cdn服务器,建立连接) -> cdn是否存在资源 -> (不存在) -> 回源处理 -> 资源返回 -> 客户端执行并渲染 当一个页面的包换的资源存在不一样的部署方式时,在排查问题时,就需要厘清最有可能导致问题的关键点。这当然取决于发生情况时候的具体表现。在网络方面的排查基本上就是回溯资源的访问过程。 回到最后,代码层面上的排查,是否存在影响代码执行,或者耗时长的操作。如前文提到的js载入的问题,其实在前端已经是老生常谈了,在html中,如果未对js添加defer,async,则js代码的执行依赖于前置js代码执行完成才会执行。这个则会阻塞页面的渲染,所以都将js置于之前。 对于复杂业务,将业务拆分成多个模块处理是一种很好的习惯,这样有利于以后维护和需求的递增。但是这样必然导致资源文件增多,当资源过多时则可能引起浏览器并发不够而耗时。左右在开发过程中建议模块化,但是发布前还是需要将资源合并压缩处理,这里也不是绝对,主要还是要看资源的数量,建议js资源文件保持在10个以内。 除此以外,对数据源这一块,可以使用缓存,目前浏览器对localStorage支持度已经很好,关键数据可以进行存储。在ajax异步成功前展示缓存数据。当然对一些数据准确性要求很高的,通过一些loading明确提示其实也是不错的选择。 结束 2020-01-01 一眨眼,已经2020了。 老许,你要老婆不要。只要你开金口,今晚就给你送来。—— 《牧马人》

本文章由javascript技术分享原创和收集

发表评论 (审核通过后显示评论):