最全高性能优化详解(6大性能优化指标方法)

性能优化对于大流量的互联网应用场景至关重要，比如：应该监控什么样的指标、以及对应应该有哪些优化策略等等，这些都是高级必备技能。

今天重点分享性能优化相关的技术@mikechen

01 性能优化

应用性能是产品用户体验的基石，性能优化的终极目标是优化用户体验。

当我们谈及性能，最直观能想到的一个词是“快”，Strangeloop在对众多的网站做性能分析之后得出了一个著名的3s定律“页面加载速度超过3s，57%的访客会离开”。

可见页面加载速度对于互联网产品的重要性。

1.缓存化

缓存可以称的上是性能优化的利器，使用缓存时需要考虑缓存命中率、缓存更新、数据一致性、缓存穿透及雪崩、Value过大等问题，可以通过mutiGet将多次请求合并一次、异步访问等方式来提升缓存读取的性能。

2.代码业务逻辑优化

业务逻辑优化经常会容易被忽略，但效果却往往比数据库调优、JVM调优之类的来的更明显。

举一个例子，12306春运抢火车票的场景，由于访问的人多，用户点击“查票”之后系统会非常卡，进度条非常慢，作为用户，我们会习惯性的再去点“查票”，可能会连续点个好几次。

假设平均一个用户点5次，则后端系统负载就增加了5倍！而其中80%的请求是重复请求。

这个时候我们可以通过产品逻辑的方式来优化，比如，在用户点击查询之后将“按钮置灰”，或者通过JS控制xx秒只能只能提交一次请求等，有效的拦截了80%的无效流量。

3.服务化

做服务化最基础的是按业务做服务拆分，避免跨业务间的互相影响，数据和服务同时拆分。同一个业务内部我们还按计算密集型/IO密集型的服务拆分、C端/B端服务拆分、核心/非核心服务拆分、高频服务单独部署等原则做拆分。

4.异步化

异步化可以利用线程池、消息队列等方式实现。

使用线程池的时候一定要注意核心参数的设置，可以通过监控工具去观测实际创建、活跃、空闲的线程数，结合CPU、内存的使用率情况来做线程池调优。

另一种是通过NIO实现异步化，一切网络IO皆可异步：RPC框架、Servlet 3.0提供的异步技术、Apache HttpAsyncClient、缓存异步接口等等。

总之，业务允许的范围，能异步化就不要同步，这是一个很重要的原则。

5.搜索引擎

复杂查询以及一些聚合计算不适合在数据库中做，可以利用搜索引擎来实现，另外搜索引擎还可以帮我们很好的解决跨库、跨数据源检索的场景。

这一类调优包括读写分离、多从库负载均衡、水平和垂直分库分表等方面，一般需要的改动较大，但是频率没有SQL调优高，而且一般需要DBA来配合参与。

性能优化是个系统性工程，涉及到后端、前端、移动端、系统网络及各种基础设施，每一块都需要做各自的性能优化。当我们系统的分析性能问题时，可以通过以下指标来衡量：

1.Web端

首屏时间、白屏时间、可交互时间、完全加载时间等。

首屏时间是指从用户打开网页开始到浏览器第一屏渲染完成的时间，是最直接的用户感知体验指标，也是性能领域公认的最重要的核心指标。

首屏时间 = DNS时间 + 建立连接时间 + 后端响应时间 + 网络传输时间 + 首屏页面渲染时间

2.移动端

Crash率、内存使用率、FPS（Frames Per Second, 每秒传输帧数）、端到端响应时间等。

Native相比于H5在交互体验方面有更多的优势，FPS是体现页面顺畅程度的一个重要指标，另外移动端开发同学还需要关注App进程的CPU使用率、内存使用率等系统性能指标。

3.后端的性能指标

QPS: 每秒钟处理完请求的次数；注意这里是处理完。具体是指发出请求到服务器处理完成功返回结果。可以理解在server中有个counter，每处理一个请求加1，1秒后counter=QPS。
TPS：吞吐量，每秒钟处理完的事务次数，一般TPS是对整个系统来讲的。一个应用系统1s能完成多少事务处理，一个事务在分布式处理中，可能会对应多个请求，对于衡量单个接口服务的处理能力，用QPS比较多。
并发量：系统能同时处理的请求数
RT：响应时间，处理一次请求所需要的平均处理时间。后端系统响应时间是指系统对请求做出响应的时间（应用延迟时间），对于面向用户的Web服务，响应时间能很好度量应用性能，会受到数据库查询、RPC调用、网络IO、逻辑计算复杂度、JVM垃圾回收等多方面因素影响。

对于高并发的应用和系统，吞吐量(TPS)是个非常重要的指标，它与request对CPU、内存资源的消耗，调用的外部接口及IO等紧密关联。

对于QPS、TPS等指标的详细参数，请看之前我分享过的：一文秒懂QPS、TPS、吞吐量等高并发指标。

以上就是高性能优化的详解，如果有兴趣更加深入的了解架构技术。