如何优化，性能优化的常见招式分享？

为什么大家觉得性能优化难？

很多人觉得性能优化难的原因，其实主要是不知道怎么去做评估，主要表现在一下几个方面：

1、不知道性能是什么？

2、不知性能的评估标准是什么？

3、不知道影响性能的相关元素是什么？

4、不知道性能问题的带来的现象是什么？

性能优化，必须知道的几个概念

关于性能的几个基础概念就像一把刀，你需要知道他可以用来削水果，还可以用来杀人。

认知，决定了你能拿它干什么，决定了能否识别到本质。

性能调优，就是一条通过现象看本质的认知之路。

性能优化中必须知道的几个概念诸如：

1、 响应时间（RT）

2、 吐出量（QPS/TPS）

3、 资源（CPU、线程等）

下面通过对这几个概念的详细剖析，进行讲解。

QPS概念扫盲

概念

QPS：Query Per Second

TPS：Transactions PerSecond

起源：数据库系统中表述性能的重要指标。

现在：对于应用系统而言，现在QPS，TPS的概念有点混淆，泛指系统单位时间的处理能力。

这两个概念是衡量性能很明确的指标，我们用它来泛指单位时间系统的处理能力。但是仅仅知道QPS/TPS的概念，就能做性能分析，性能调优了吗？是哪些因素会影响QPS/TPS？

接下来我一层层来剖析：响应时间模型，线程模型，已经线程和资源之间的关系。

深入理解响应时间组成模型

很多人对响应时间的组成是不清晰，导致不能很好的判断，时间消耗在了什么地方。明白时间消耗的节点是很重要的一件事。

不知道响应时间组成的优化就像是乱枪打鸟。需要明白时间消耗在什么地方，是什么原因造成的消耗。

不要认为只有CPU消耗；更不要认为加CPU核数就可以解决问题。

通常是通过埋点的方式把代码执行切分成一段一段的片段，获取各个节点、各类节点的消耗，用于观察性能情况，定位性能瓶颈点；链路上的埋点，可以配合监控系统统一来看，阿里是自己实现了一个简单的埋点类。

响应时间是程序（进程、线程）在资源（CPU）运行的一个体现。所以，资源和程序运行的载体会影响这个结果。下面深度理解JAVA的线程模型。

深入理解线程模型

进程/线程是程序运行的载体，所以深入理解线程的机制有助于帮助性能分析。

请看下图

左上的图，是线程几个状态之间的扭转。

左下的图，是线程在锁的争用时候的运行态。

右上的图讲linux中，java主进程、java线程/LWP轻量级进程和CPU调度，CPU绑定运行的模型：

1、线程/进程是操作系统调度的关键资源。

2、理解器运行机制有利于知道一个请求中的运算是消耗在什么节点。CPU只是一个点，其他资源也是会影响线程的执行。

3、多线程情况下，线程不一定是满转的，遇到共享资源争用的时候，会造成阻塞。

线程和CPU是程序运行的宝贵资源。资源不足会造成性能问题；资源富足优惠造成资源浪费。到底匹配多少资源才是最优的呢？

下一步解释最优线程数，如何最优化资源配比，理解资源之间的关系。

深度剖析最优线程数

最优线程数定义

1. 尽可能保持应用对资源的最大化使用。
2. 当线程数较少的时，有压力情况下，可能造成线程资源不足，请求需要等待线程释放后才能处理。
3. 当线程数较多的时，线程自身也是需要消耗内存资源的，导致资源的浪费，同时，线程较多的时候对于线程的调度和争用也会影响性能。

如何确定或者使用尽量少的线程，就能让当前的资源高效利用呢？

可能大家有个疑问：怎么最优线程数，有毛用啊！我反正给他很多线程，这不就完事了吗？比如最后线程是100，我给你200（好，你是牛人，你是有钱人，哈哈）

但是我认为：对资源使用情况的合理理解和分析，是很重要的，尤其是如果你是个老板，你要关心钱用了多少吧，那些钱不该花吧！如果你是个技术人员，你要告诉你的老板这些是啊，毕竟你是一个有追求的程序员（不然老板就开了你。。。）

为了剖析最优线程数和资源之间的关系，下面我讲一步步分解，让大家理解。

深度理解瓶颈资源

为了理解瓶颈资源，假设一个业务场景：

下面通过对程序运行态通过图表的方式是呈现出来，便于大家理解瓶颈资源、多资源情况下的线程调度。

以5ms作为一个时间帧。

第1个5ms如下

cpu同时可以运4个线程，因此请求11，21,31,41执行，其余5个请求，等待CPU资源。

第2个5ms如下

cpu同时可以运4个线程，其余5个请求，等待CPU资源。

第3个5ms如下

第4个5ms如下

第5个5ms如下

通过快照图，我可以看到什么？

一个多资源的程序中：对资源的争用表现为对瓶颈资源的争用，性能情况会受制于瓶颈资源。

瓶颈资源可以用水桶原理来解释，如下图。

基于上述对线程、瓶颈资源的梳理，我们很容易提炼出QPS的理论公式，大家可以看下面的公式，如果觉得烧脑，可以多看几遍。

深入理解QPS公式

最优线程公式：

1、 最优线程数量=线程总时间/瓶颈资源时间 * 瓶颈资源并行数

2、 一个线程1S可以处理的请求数

3、 1000/线程总时间

QPS公式1：QPS =最优线程数量* 1000/线程总时间；

QPS公式2：QPS=1000/瓶颈资源时间 * 瓶颈资源并行数。

这个公式里隐含了一些有趣的解释，大家可以去揣摩下。

性能压测

——从理解瓶颈到如何识别瓶颈

前面讲的都是理论，很多很多理论，下来大家可以花些时间理解。主要目的是让大家对性能有个可量化的指标衡量，知道指标了，那么下一步就是讲如何获得这些指标，如果通过这些指标发现问题。

接下来的章节，如何识别瓶颈资源，常用的方式是压测，下面是压测模型图（没有讲怎么使用jmeter压测等）。

压测模型抽象

性能压测是有方法，有模式，有目标的。如何对压测进行管理，如何创造压力，如何准备被测系统，如何准备压测数据，如何收集压测数据，如何分析压测数据。是要进行稳定压测，还是要进行瓶颈压测等等。

性能压测是一件很专业的事情，对于压测，理解压测的组成环境是很重要的，有的时候，压测的环境就是压测瓶颈。

压测环境组成

这里讲两个环境：

1、压力机环境：不要认为压不上去了就是被测系统的问题，曾经也遇到过jmeter处理压测响应数据的性能瓶颈，导致一致压不上去。

2、依赖系统/数据的影响：举个例子比如集群部署后，线上A调用B应用，A是100台，B是1000台；但是线下性能实验室A和B是1：1关系。1：1压测出来的数据是否就是线上的数据呢，这里是有一个问号的。

压测需要注意的一些事项：

• 理解环境
• 压测环境和线上环境的不同
• 避免压测环境的不同造成压测结果的不可行
• 吞吐量和响应时间的取舍和平衡
• 确定合理的性能预期值
• 适可而止
• 不做过度的优化，在性能和其他因素（架构，可维护性）等的平衡
• 选取合适的压测场景设计用例
• 天花板
• 充分利用资源
• 不过度使用资源

从识别瓶颈到如何进行优化

内容可以见下图

如何识别瓶颈？永远也不会废的方法，隔离法和替换法。当你觉得对哪一块怀疑（CPU、IO、线程、压力机、外围系统）的时候，可以快速的使用这些方法识别。

比如你可以使用mock，挡板，更换机器。

这两个方法很简单，比冥思苦想有用多了，所以性能优化，不要把自己逼疯了。

优化手段，可以见图中方式，性能优化有一定招式，但是结合具体场景后，有各种取舍，不要一味生搬硬套。

Q&A:

Q1 什么时候需要优化性能？需要提前考虑么？

我认为性能的问题是一个技术人员、架构师骨子里的东西（需要提前考虑）；但是实施的步骤是根据你的业务场景、业务量、业务增量、系统当前的容量，系统的扩展性等问题来考虑（比如是否可以水平扩展应对等），不用做过渡的超前设计。

Q2 上图中的N+1那个N指什么？

N就是对CPU的核数，这里只是理解了很多人/或者网上提高的一些经验值，这些经验值有可能是在没有考虑多资源的情况下的值，但是有可能你的系统就不是一个CPU密集运算性系统。

Q3 比较感兴趣耗时统计工具，是开源的么？有移动端的统计工具么？

耗时统计的这个东西，我觉得主要是看埋点。你用什么东西埋点，对于阿里体系也就是一个简单的类。没有那么复杂；对于链路上的，我认为可以打印各个节点的达到时间，最后监控来看。

移动端的工具，我接触很少，sorry。

Q4 测试性能的机器 怎么选 有的说要高配，有的说要烂机器。

没那么多讲究，不要听很多大公司的忽悠，不要全听咨询师的，黑一把咨询师。举个例子，原来都说我们要用大型机，然后要用小型机，现在大家都用 pcserver。

好了，这篇文章的内容长行号就和大家分享到这里！