strick

  最近阅读了很多优秀的网站性能优化的文章,所以自己也想总结一些最近优化的手段和方法。

  个人感觉性能优化的核心是:减少延迟,加速展现。

  本文主要从产品设计、前端、后端和网络四个方面来诉说优化过程。

一、产品设计

  在网上看到一句话:好的性能是设计出来的,而不是优化出来的。

  感觉好有道理,如果将性能瓶颈扼杀在摇篮里,那么后期的维护成本将变得非常低,并且在避免改造后,都不需要浪费资源了。

1)聊天改版

  最近公司有个聊天活动做改版,改版上线后惊喜的发现,监控数据居然减少了将近20W。

  

  更深一步的探究,才知道在页面初始化时,会发一个请求,去获取一些文案,但其实这些文案都是写死的,完全可以写到页面本地。

  如果在产品设计时,就不是通过接口读取的方式,那么就可以大大减少浏览器和服务器之间的通信。

2)数据迁移

  公司有一个审核系统,最近审核人员反应系统使用起来越来越卡。排查后发现,定位到性能瓶颈,是因为数据表巨大导致的,目前已有6千万条。

  其实在一开始设计时,就该能预估到,未来的数据量,感觉还是偷懒了,想快速完成。感叹前人挖坑,后人埋坑。

  起初是想分表,但思虑后还是决定不那么做,最后采用的是MySQL归档

  前前后后花了两周的时间,才将方案落地实现,涉及到运维、QA和我们前端组,人力成本无疑是巨大的。

  其实在每次完成优化后,可以再想想能不能将问题泛化,扩大维度,想想其他地方是否有类似问题,总结经验供他人学习,以及对未发生的问题进行预判。

3)大批量的504

  这是在上线监控平台后不久发现的,504 的请求量太多,这类通信错误居然占了25%~30% 左右。

  经过排查定位到一个常规的翻卡活动中,产品设计出现了严重的问题。

  在进行一个翻卡操作时会请求两个接口,并且每个接口各自发送 3 次通信,这样会很容易发生 504 错误,每天大约有1500个这样的请求。

  首先是给其中一张表加了个索引,然后是将两个接口合并成一个,并且每次返回 20 条以上的数据,这样就不用频繁的发起请求了。

  经过改造后,每日的 504 请求从 1500 个左右降低到 200 个左右,减少了整整 7.5 倍,效果立竿见影,大部分的 504 集中在 22 点到 0 点之间,这段时间的活跃度比较高。

  还有一个令人意外的发现,那就是监控日志的量每天也减少了 50W 条。 

二、前端

  前端的优化手段非常多,常规的其实就是延迟请求和减少页面渲染次数。

1)预请求

  数据预请求是将数据预请求的时机由业务发起请求的时机,提前到用户点击时,并行发送数据请求,缩短数据等待时间。

  这个需要客户端配合,在Webview启动的时候,并行的去请求首屏需要的数据。

  经过观察发现每次请求后端数据的API大概要花100~200ms,如果把这段时间省下来,那么也能减少白屏时间。

  在与客户端沟通时,他们还是表现的比较抗拒的,在他们看来这点时间微不足道,还会增加他们的工作量。

  有个人还一直强调浏览器内置的缓存规则是一剂灵药,绝对可以提升页面的性能,经过讨价还价后敲定最终的预请求方案

2)预加载和懒加载

  预加载和懒加载特指的是图片的加载,其实就是延迟请求时机。

  两者的核心算法就是计算图片的相对位置,具体参考于此

  这两招非常有效,可以说是立竿见影,尤其是页面中图片量较多以及尺寸较大时,能瞬间提升页面加载。

  之前做过一次偏动画的宣传页,在进入页面时,立刻请求所有图片,直接白屏好几十秒。

3)串行变并行

  有一张活动页面,交互并不多,但是要展示的数据需要经过后台比较复杂的计算后才能得到。

  一开始是将所有的数据都包含在一个接口中,这就导致页面发起请求后,要白屏好几秒后,才能慢慢加载。

  用户的等待时间很长,经过排查后发现,其实可以将一些配置参数提取到单独的一个接口中,核心的数据再抽取到另一个接口中。

  这样就是将一个串行的接口分离成两个并行的接口,先快速的让用户看到整个页面的大结构,例如头图、规则等信息。

  然后在将数据渲染到合适的位置,形成了一个时间差,对用户更加友好。

三、后端

  后端主要涉及是Node.js和数据库的优化,我们组涉及到的此类性能瓶颈并不多,但也会有一些。

1)内存泄露

  自研了监控平台,在刚上线时,就遇到了性能问题,首先是采集的参数在大批量的发送给存储的服务器时,服务器宕机了。

  因为每秒就有几百甚至几千的请求发送过来,服务器需要整理数据后加入到数据库中,当数据量暴增时,服务器就会来不及处理。

  这个性能瓶颈发生后,马上加入任务队列,服务器就能平稳的运行了。

  之后又出现了另一个问题,CPU会在不特定时间段(例如21~22、23~02等)飙到70%,内存也是一路飙升不会下降,明显是出现了内存泄漏,具体的排查过程可以参考于此

  开通了阿里云的 Node.js 性能平台,在前前后后调试了三周,有点像探案的过程,才最终定位到一段最为可疑的代码。

  原来是为外部的一个对象反复注册了一个事件,应该是形成了一个闭包,让闭包内的变量都无法释放。

2)数据库

  仍然是在研发监控平时时遇到的性能瓶颈,这次主要体现在数据库。

  监控的日志我都存储在MySQL中,每日 70W 条记录,数据量很快达到了千万级别,在做查询时,变慢了很多。

  那么就得让索引上了,亚洲舞王尼库拉斯赵四曾说过:一个索引解决不了的,那就来两个索引。

  我也是这么做的,加了好多个索引,但维度模糊查询,这个不是加索引能解决的,尝试了很久,最终还是决定迁移到ElasticSearch中。

  效果也是立竿见影的,几千万条数据,几秒钟就出了结果,令我惊叹不已。

  这里顺便说下,我会在什么场景中选择 MongoDB 作为数据库的。

  MySQL是一种关系型数据库,会事先声明表结构,那么对于数据结构不定的记录,存储起来会比较费劲。

  例如记录中有许多JSON格式的数据,就比较适合存在 MongoDB,当然了,这类数据也可以转换成字符串存在 MySQL 的一个字段中。

  只是在读取和写入时,要经过序列化和反序列化的操作,并且如果要查询JSON数据的某一个字段时,MySQL中就只能模糊查询了。

  但是平时的话,我还是会尽量将数据存在 MySQL 中,有个很直接的原因是因为线上的 MySQL 有一个功能完善的可视化界面,而 MongoDB 没有,只有一个我自制的简陋工具。

3)管理后台挂起

  之前也会偶尔有管理后台服务挂起的情况发生,但最近会在每天的10点左右发生。

  在下图中,一分钟内server服务瞬间飙到了 100%,不得不让我引起注意。  

  

  查找那段时间的日志,发现有很多送礼的记录,反向查询后,定位到一个导出链接。

  初步以为是这个功能导致的服务挂起,询问相关操作人员,得到当时的操作过程。

  在预发环境模拟,得到的结果是可以正常导出,所以应该可以排除它的嫌疑。

  回想到前天也发生了挂起(不过前天的CPU都比较正常),再次翻查日志,新发现直指审核模块。

  与审核人员沟通后,她们向我一顿吐槽,大倒苦水,说这系统11点后,经常卡顿转圈。

  这个系统后续有很大的优化空间,那么目前首要任务是解决服务挂起的问题。

  可以想到的是将审核模块单独配置一台服务器,做成独立服务,这样也便于观察。

  服务切换其实就是将特定规则的API指向另一个服务,代码和逻辑都不需要改动,非常方面。

  隔天发现仍然会挂起,但是挂起的服务可以定位到审核模块,运维也找到了一条发生504的接口。

  前一天发生的挂起,也是这个接口引起的,顺着这条接口查看代码,并没有发现什么异常。

  打开日志,发现这个接口的响应的确非常慢,要几分钟了,再去查其中涉及到的SQL查询语句,发现也很耗时。

  将语句拿到数据库中执行 EXPLAIN 命令,影响的行数要 311W 多条,命中的索引是 idx_create_time。

  而去掉其中的一个日期限制后马上降到 69 条,命中的是一个联合索引,回到代码中,查看逻辑后,发现这个时间限制是多余的,马上就将其去除。

  还有一条SQL语句运行也很慢,影响的行数要 16W 多条,命中的索引是 idx_status,而这个 status 其实只有几个可选的关键字,会影响查询效率。

  于是再创建一个联合索引,影响的行数降到 1785 条,优化后,再反馈给审核人员。

相关文章:

猜你喜欢