认识达内从这里开始

性能优化一直以来都是web前端开发程序员需要长期关注的一个问题，而本文我们就通过案例分析来简单了解一下，性能优化都需要做好哪些准备工作。

一、前端

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

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没有，只有一个我自制的简陋工具。

【免责声明】本文系本网编辑部分转载，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题，请在30日内与管理员联系，我们会予以更改或删除相关文章，以保证您的权益!更多内容请加danei456学习了解。欢迎关注“达内在线”参与分销，赚更多好礼。