性能优化｜有条不紊的方法

一个环境可能由数据库、Web 服务器、负载均衡和自定义应用程序组成，所有这些都在操作系统上运行——裸机或虚拟机，这只是软件部分。

CPU、内存、硬盘、外部存储系统和网络基础设施，这些软件运行必不可少的硬件。

无论软件或者硬件中的任何一个组件都是潜在的问题来源。

在不清楚组件使用场景或者没有提供清晰线索的情况下，即便其中一个组件的性能问题，也可能是复杂而神秘的。我们看到 SQL 查询最近突然变慢了，是数据库的问题，还是自身业务数据导致？很难根据现象定位到原因。

另一个复杂的因素是好或坏性能可能是主观的：一个用户不可接受的延迟可能对另一个用户是可以接受的。如果没有明确识别问题的方法，不仅很难知道问题是否存在，而且很难知道问题何时得到解决，如何才算解决。所以要允许按照一定标准去量化问题，否则问题很难得到解决。

性能分析经常采用「假设验证」的方式被随机分析，猜测问题可能出在哪里，然后改变事情直到问题消失。虽然这可能产生正向结果，但是它也可能是耗时的、破坏性的，并且最终可能会忽略某些问题。

本文描述了当今用于性能分析的有效惯用方法，也是火焰图作者一直提倡的USE方法

对于所有的资源，查看它的使用率，饱和度和错误。

整体流程

开始

通常可以在线上真实环境或者压测环境开始分析，首先要保证有足够的流量，否则很难发现真正问题。

识别资源

这块主要就是分析资源指标使用情况，我列举一些资源，如下：

• CPU，可能存在CPU利用率过高问题，也可能存在CPU利用率过低问题，也可能存在CPU降频问题...

• 内存，是否存在内存泄漏或者内存使用率过高

• 网络，网络存在丢包、延迟过高、带宽不足等问题

• 磁盘，分析磁盘IOPS、是否存在磁盘坏道

首先要查看你最关心的部分，直到找到性能瓶颈为止，具体选择什么工具进行分析，请参考之前的文章。

性能调优｜成都核酸系统篇

性能优化｜火焰图篇

问题分析

整个过程采取问题陈述的方法进行每个资源类型的问题分析，举一个延迟过高例子。

1. 一次请求响应时间需要5s，为什么呢？

客户的容忍度是3s以内，所以必须优化，为什么一次简单的请求需要这么高的延迟呢？

1. 网络延迟主要发生在什么地方呢？

通常网络延迟可能发生在网络和服务处理两部分中，其中网络部分又包括：DNS解析+网络请求+网络传输时延；其中任何一个部分产生耗时都可能导致时延过高。

1. 我怎么确定延迟发生在哪里呢？

理论上网络链路上的每一个环节都应该有自己的分位数延迟指标，这里注意要使用分位数，而不应该使用平均数，就好比有人告诉你这个河水的平均深度是0.5米，那么你到底过还是不过呢？

查看每一个环节的延迟指标，看看最耗时的环节发生在什么位置；如果没有进行相应的监控指标建设，可以使用ping、tcpdump等工具进行网络链路耗时分析。

逐个链路分析一遍，发现耗时发生在B服务上。

1. 为什么B服务会发生耗时呢？

因为B在处理过程中CPU资源用尽了，说明服务已经饱和，外面过来的请求都需要排队，从而导致了请求延迟过高。

1. B的什么逻辑占用了这么多的CPU资源呢？

通过火焰图分析，B服务中执行了多次压缩算法。那么就要查看这些压缩算法是否有必要，去除或者替换不必要的消耗是最好的性能优化方式。

自己曾经碰到过一个团队，出现了CPU占用率过高的问题，发现他们数据每次存储到数据之前都要进行一次数据zip压缩，目的是防止占用过多磁盘存储资源。通过分析发现数据普遍在200字节以内，也就是压缩前后并没有太多的差别，同时占用了非常高的CPU资源，最后给出了两种方案，要么换成zstd等高性能压缩方案；要么直接去掉该压缩算法。

错误分析

在性能压测过程中，查看所有可以查看的日志，不要放过任何一个错误，即便这个错误看起来跟自身服务没什么关系。

比如服务自身在运行过程中一直输出错误日志，因为日志写文件占用过多内存，导致服务自身的内存紧张，从而发生了GC，GC又占用了过高的CPU资源，最后导致服务运行过慢。

所以有时表面看起来无足轻重的问题，实际上都是相互影响的。

总结

在日常工作中，公司很难有可以了解所有组件的专业人员，即便某个领域的专业人员也非常可贵。

突如其来的，性能优化的责任就落到各自产品线开发人员身上。

有同学在做性能优化过程中，一直盯着 top 看，其实也看不出什么问题，究其原因，不知道还有什么可用的工具。这是一个误区，不要担心工具，基本上你能想到的性能量化工具都是存在的，当你掌握正确分析方法之后，再去了解工具的使用方式。

性能分析方法可以提供一种有效的方法来分析系统或组件并确定问题的根本原因，而无需深厚的专业知识。

原创不易，随手关注或者”在看“，诚挚感谢！