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

1.资源

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

软件资源有:

2.资源使用的三个维度

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

2.1 使用率

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

2.2 饱和度

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

2.3 错误

软件运行出错。

3.USE 方法

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

3.1 工作流程

USE方法流程

  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%


↙↙↙阅读原文可查看相关链接,并与作者交流