上回说了软件性能问题错误修复大法鉴赏，如果不给出正确方法，那就止步于笑谈。那么软件出了性能问题，究竟应该如何去定位呢？

1.资源

首先，我们要明白一件事，软件发生性能问题，必定是资源不够用了。资源分为硬件资源和软件资源，硬件资源有：

• CPU：内存插槽，核心，硬件线程
• 内存：DRAM，缓存
• 网络：以太网，WIFI，4G
• 存储设备：硬盘
• 控制器：储存，网络

软件资源有：

• 互斥锁：锁的平均占用的时间是一个重要的指标，等待锁的队列侧面反映了软件的饱和度
• 线程池：有限的线程处理海量的工作，必然会有事务等待处理
• 进程/线程/协程容量：系统的进程/线程的数量是有上限的，在 golang、erlang 这种原生支持协程的语言中，协程的数量也不是无上限的
• 文件描述符容量：系统的文件描述符也是有上限的

2.资源使用的三个维度

资源在使用时有三个维度：utilization（使用率），saturation（饱和度），errors（错误）。我们必须要先弄清楚这三个概念，然后才能查找性能问题。

2.1 使用率

在规定的时间内，资源用于服务工作的时间百分比。

2.2 饱和度

资源不能用于服务额外工作的程度，通常有等待队列。饱和程度可以用排队长度或者排队所花时间来衡量。

2.3 错误

软件运行出错。

3.USE 方法

研究这三个维度，查找性能问题的方法就叫USE 方法，USE 方法是一种研究高使用率、高饱和状态下性能问题最有效的方法。

3.1 工作流程

1. 错误检查优先级最高的，不仅仅时因为修复错误的优先级比较高，更因为错误更容易被发现（只要检查错误日志）。
2. 使用率和饱和度也是有顺序的，只有当使用率高达 100% 的时候，降低饱和度才有意义 [1]。
3. 当你使用 USE 方法的时候，很可能发现了不止一个性能问题，你关心的问题并不会在一开始就出现，你需要多选择几项资源，才能找到你所关心的性能问题。不过，理论上所有的性能问题都应该被修复（在成本允许的情况下）

3.2 资源检查

使用率有两个红线：60%，100%

根据排队理论，60% 意味着优先级较低的工作将会被排在队列后面执行。100% 意味着该资源出现了严重的性能瓶颈，亟待解决。

饱和度：任何程度的饱和都是性能瓶颈。

错误：错误都是值得研究的，不仅仅是为了解决性能问题。

3.3 收费站现象

假设高速公路的收费站，一整天的使用率是 40%，你能据此断定收费站在早高峰的时候没有排队吗？

收费站现象表明了资源即使大部分情况下都是绰绰有余，但是系统依然会出性能问题，只是需要在特定时间点才能观察到。因此，我们还需要预留应急资源，或者异步处理分担峰值压力。

4.作者的话

4.1 吐槽

我一个研究服务端性能的文章竟然找不到话题节点，只能先借用移动性能测试的节点了，麻烦管理员加个服务端性能测试节点。

4.2 性能问题正确的定位方法

USE 法

4.3 注

[1] 更准确地说，应该是瞬时使用率高达 100%