性能课程笔记（五）性能分析思路[转载高楼]

转载 课程地址：https://time.geekbang.org/column/article/178068
（ps：这个课程都是老师实战经验，还有很多交流）

我还年轻的时候，经常听一些大会或者演讲。有些人说，思路逻辑非常重要。我那时就想，你肯定是瞎忽悠的，因为我怎么就没听懂你说的思路呢？

而现在轮到自己来写或者讲一些东西的时候，才发现他们说得很对，而我之所以不理解，也是有原因的。

性能分析思路和具体的实现之间，有一道鸿沟，那就是操作的能力。之前我为什么听不懂那些人的思路，其实是因为我没有操作的功底。

而有了操作的功底之后，还有一个大的鸿沟要越过去，那就是从操作到对监控计数器的理解。这一步可以说让很多性能测试人员都望而却步了。

但是这还不算完，这一步迈过去之后，还有一个跳跃，就是相关性分析和证据链分析的过程。
如此一来，就会得到一张性能测试分析的能力阶梯视图，如下：

1. 工具操作：包括压力工具、监控工具、剖析工具、调试工具。
2. 数值理解：包括上面工具中所有输出的数据。
3. 趋势分析、相关性分析、证据链分析：就是理解了工具产生的数值之后，还要把它们的逻辑关系想明白。这才是性能测试分析中最重要的一环。
4. 最后才是调优：有了第 3 步之后，调优的方案策略就有很多种了，具体选择取决于调优成本和产生的效果。

那么怎么把这些内容都融会贯通呢？下面我们就来说说性能测试分析的几个重要环节。

应该说，从我十几年的性能工作中，上面讲的这些内容是我觉得最有价值的内容了。在今天的文章中，我们将对它做一次系统的说明。我先把性能分析思路大纲列在这里：

1. 瓶颈的精准判断；
2. 线程递增的策略；
3. 性能衰减的过程；
4. 响应时间的拆分；
5. 构建分析决策树；
6. 场景的比对。

瓶颈的精准判断

一 、TPS 曲线

对性能瓶颈做出判断是性能分析的第一步，有了问题才能分析调优。

之前有很多人在描述性能测试的过程中，说要找到性能测试中曲线上的“拐点”。我也有明确说过，大部分系统其实是没有明确的拐点的。

举例来说，TPS 的视图如下：

TPS图1

显然，这是一个阶梯式增加的场景，非常好。但是拐点在哪呢？有人说，显然在 1200TPS 左右的时候。也有人说了，显然是到 1500TPS 才是拐点呀。但是也有人说，这都已经能到 2000TPS 了，显然 2000TPS 是拐点。
我们再来看一下这张图对应的响应时间视图：

是不是有人要说响应时间为 4.5ms 时是拐点了？

其实这些对拐点的判断，都是不合理的。如果我们对 TPS 的增加控制得更为精准的话，那么这个 TPS 的增加是有一个有清晰的弧度，而不是有一个非常清晰的拐点。

但是至少我们可以有一个非常明确的判断，那就是瓶颈在第二个压力阶梯上已经出现了。因为响应时间增加了，TPS 增加得却没有那么多，到第三个阶梯时，显然增加的 TPS 更少了，响应时间也在不断地增加，所以，性能瓶颈在加剧，越往后就越明显。

那么我们的判断就是：

1. 有瓶颈！
2. 瓶颈和压力有关。
3. 压力呈阶梯，并且增长幅度在衰减。

如果你觉得上面的瓶颈还算清晰的话，那么我们再来看一张图：

在这个 TPS 的曲线中，你还能判断出拐点在哪吗？

显然是判断不出来拐点的，但是我们根据图得出以下几个结论：

1. 有瓶颈！
2. 瓶颈和压力有关。
3. 压力也是阶梯的，但是并没有明确的拐点。

我们再来看一个 TPS 图：

看到这张图，是不是明显感觉系统有瓶颈呢？那么瓶颈是不是和压力大小有关呢？

这种比较有规律的问题，显然不是压力大小的原因。为什么呢？因为 TPS 周期性地出现降低，并且最大的 TPS 也都恢复到了差不多的水位上。所以，即使是压力降低，也最多降低最大的 TPS 水位，会让问题出现得更晚一点，但是不会不出现。

综合以上，如果画一个示意图的话，TPS 的衰减过程大概会如下所示：

1. 随着用户数的增加，响应时间也在缓慢增加。
2. TPS 前期一直都有增加，但是增加的幅度在变缓，直到变平。

在这样的趋势图中，我们是看不到明确的拐点的。但是我们能做的清晰的判断就是：有瓶颈！

所以对 TPS 曲线来说，它可以明确告诉我们的就是：

1. 有没有瓶颈：其实准确说所有的系统都有性能瓶颈，只看我们在哪个量级在做性能测试了。
2. 瓶颈和压力有没有关系：TPS 随着压力的变化而变化，那就是有关系。不管压力增不增加，TPS 都会出现曲线趋势问题，那就是无关。

这时你可能会问，为什么不看响应时间就武断地下此结论呢？其实响应时间是用来判断业务有多快的，而 TPS 才是用来判断容量有多大的。

二、响应时间的曲线

我们还是来看看响应时间，下面看一张响应时间图：

它对应的线程图是：

多明显的问题，随着线程的增多，响应时间也在增加，是吧。再来看它们对应的 TPS 图：

到第 40 个线程时，TPS 基本上达到上限，为 2500 左右。响应时间随着线程数的增加而增加了，系统的瓶颈显而易见地出现了。

但是，如果只让你看 TPS 曲线，你是不是也会有同样的判断？那就是：有瓶颈！并且和压力有关？所以说，其实 TPS 就可以告诉我们系统有没有瓶颈了，而响应时间是用来判断业务有多快的。

后面我们还会提到响应时间会是性能分析调优的重要分析对象。

三、线程递增的策略

讲完响应时间之后，我们再来看下线程递增。

在见识了很多性能测试人员做的场景之后，必须得承认，有些场景的问题太多了。

首先，我们来看两个场景的执行对比。

场景 1 的线程图：

场景 1 的 TPS 图：

场景 1 的响应时间图：

场景 2 的线程图：

场景 2 的 TPS 图：

场景 2 的响应时间图：

这两个场景的比对如下：

有了这些对比数据之后，你是不是觉得哪里似乎是有问题的？

对的！

TPS 都是达到 400，但两个场景中线程递增的策略不同，产生的响应时间完全不同。虽然都没有报错，但是第一种场景是完全不符合真实的业务场景的。这是为什么呢？

在场景的执行过程中，首先，响应时间应该是从低到高的，而在场景 1 中不是这样。其次，线程应该是递增的，而场景 1 并没有这样做（这里或许有人会想到秒杀的场景，认为场景 1 符合秒杀的业务设定，这个问题我们稍后提及）。最后，在两个场景中，TPS 的上限都达到了 400TPS。但是你可以看到，在场景 2 中，只要 40 个线程即可达到，但场景 1 中居然用到了 500 线程，显然压力过大，所以响应时间才那么长。

其实在生产环境中，像场景 1 这样的情形是不会出现的。如果它出现了，那就是你作为性能测试的责任，因为你没有给出生产环境中应该如何控制流量的参数配置说明。

同时，我们从上面的场景对比可以看到，对一个系统来说，如果仅在改变压力策略（其他的条件比如环境、数据、软硬件配置等都不变）的情况下，系统的最大 TPS 上限是固定的。

场景 2 使用了递增的策略，在每个阶梯递增的过程中，出现了抖动，这就明显是系统设置的不合理导致的。设置不合理，有两种可能性：

1. 资源的动态分配不合理，像后端线程池、内存、缓存等等；
2. 2. 数据没有预热。

我们再回到之前说的秒杀场景。

说到秒杀场景，有人觉得用大线程并发是合理的，其实这属于认识上的错误。因为即使线程数增加得再多，对已经达到 TPS 上限的系统来说，除了会增加响应时间之外，并无其他作用。所以我们描述系统的容量是用系统当前能处理的业务量（你用 TPS 也好，RPS 也好，HPS 也好，它们都是用来描述服务端的处理能力的），而不是压力工具中的线程数。这一点，我在第 5 篇文章中已经做了详细的解析，你可以回去再看看。

那么，对于场景中线程（有些工具中叫虚拟用户）递增的策略，我们要做到以下几点：

1. 场景中的线程递增一定是连续的，并且在递增的过程中也是有梯度的。
2. 场景中的线程递增一定要和 TPS 的递增有比例关系，而不是突然达到最上限。后面在场景的篇幅中我们会再说它们之间的比例关系。
3. 上面两点针对的是常规的性能场景。对于秒杀类的场景，我们前期一定是做好了系统预热的工作的，在预热之后，线程突增产生的压力，也是在可处理范围的。这时，我们可以设计线程突增的场景来看系统瞬间的处理能力。如果不能模拟出秒杀的陡增，就是不合理的场景。

这里给出我做性能场景递增的经验值：

当然这里也不会是放在哪个系统中都适合的递增幅度，你还是要根据实际的测试过程来做相应的判断。

有了这些判断之后，相信大家都能做出合理的场景来了。

四、性能衰减的过程

有了瓶颈的判断能力，也有了线程递增的意识，那么下面在场景执行中，我们就要有判断性能衰减的能力了吧。

来，我们先看一个压力过程中产生的结果图。

在递增的压力过程中，随着用户数的增加。我们可以做几次计算。

第一次计算，在线程达到 24 时，TPS 为 1810.6，也就是每线程每秒发出 75.44 个请求。

第二次计算，在线程达到 72 时，TPS 为 4375.1，也就是每线程每秒发出 60.77 个请求。

第三次计算，在线程达到 137 时，TPS 为 5034，也就是每线程每秒发出 36.74 个请求。

通过这三次计算，我们是不是可以看到，每线程每秒发出的请求数在变少，但是整体 TPS 是在增加的。

我们有很多做性能测试的人，基本上，只看 TPS 和响应时间的时候，在上面这个示例中，肯定会一直往上加用户。虽然响应时间在增加，但是增加得也不多嘛。

但实际上，通过我们的计算可以知道，性能是在不断地衰减的。我们来看一张统计图：

通过红线的大致比对可以知道，当每线程每秒的请求数降到 55 左右的时候，TPS 就达到上限了，大概在 5000 左右，再接着往上增加线程已经没有用了，响应时间开始往上增加了。

这就是性能衰减的过程（题外话，在上图中，其实还有一个问题，就是在红线前面，性能在上升的过程中有几次抖动，这个抖动到后面变大了，也变频繁了，如果这是必然出现的抖动，那也是配置问题，希望你注意到这一点）。

为什么要这么细致地描述性能衰减的过程呢？

其实我就是想告诉你，只要每线程每秒的 TPS 开始变少，就意味着性能瓶颈已经出现了。但是瓶颈出现之后，并不是说服务器的处理能力（这里我们用 TPS 来描述）会下降，应该说 TPS 仍然会上升，在性能不断衰减的过程中，TPS 就会达到上限。

这也是前面我说的，性能瓶颈其实在最大 TPS 之前早就已经出现了。

那么我们是不是应该在性能衰减到最大 TPS 时就停止场景呢？这个不一定的哦。

因为停不停场景，取决于我们的场景目标，如果我们只是为了得到最大 TPS，那确实可以停止场景了。但是，如果我们要扩大化性能瓶颈，也就是说为了让瓶颈更为明显，就完全不需要停止场景，只要不报错，就接着往上压，一直压到我们要说的下一个话题——响应时间变长，需要拆分。

五 、响应时间的拆分

在性能分析中，响应时间的拆分通常是一个分析起点。因为在性能场景中，不管是什么原因，只要系统达到了瓶颈，再接着增加压力，肯定会导致响应时间的上升，直到超时为止。

在判断了瓶颈之后，我们需要找到问题出现在什么地方。在压力工具上看到的响应时间，都是经过了后端的每一个系统的。

那么，当响应时间变长，我们就要知道，它在哪个阶段时间变长了。

我们看下这张图。

这应该是最简单的一个压力测试逻辑了。一个应用，一个 DB，结果也拆分出了 8 个时间段，这还是在我没有加上压力工具自己所消耗的时间的情况下。

如果我们要分析压力工具中的响应时间，拆分的逻辑就是上面这个示意图。

但是在真实的场景中，基本上不是这样的。如果是内网，那基本上都是连在一个交换机上，所以通常是这样的：

在这样的拓扑中，我们仍然可以拆出来 t1 到 t8 的时间。只是实际动手的时候，思路一定要清晰，时间拆分是从哪里到哪里，要画出来，不能混乱。

我们有很多手段可以进行时间的拆分，当然要看我们的应用支持哪一种。

如果我们是这样的架构，拆分时间应该是比较清楚的。

首先我们需要查看 Nginx 上的时间。日志里就可以通过配置 request time
timeupstream_response_time 得到日志如下信息：

14.131.17.129 - - [09/Dec/2019:08:08:09 +0000] "GET / HTTP/1.1" 200 25317 0.028 0.028

最后两列中，前面是请求时间的 28ms，后面是后端响应时间的 28ms。

同时，我们再到 Tomcat 上去看时间。

172.18.0.1 - - [09/Dec/2019:08:08:09 +0000] "GET / HTTP/1.1" 200 25317 28 27 http-nio-8080-exec-1

请求时间消耗了 28ms，响应时间消耗了 27ms。

接着再来看一下前端的时间消耗。

从这里可以看到，从发出请求到接收到第一个字节，即 TTFB 是 55.01ms，内容下载用了 11.75ms。从这就可以看得出 Nginx 基本上没消耗时间，因为它和 Tomcat 上的请求响应时间非常接近。

那么网络上的消耗时间怎么样呢？我看到有很多人用 TTFB 来描述网络的时间。先来说明一下，TTFB 中显然包括了后端一系列处理和网络传输的时间。如下图所示。

下面的紫色点是指要接收的内容。上面的红色线就是 TTFB。
如果接收完了呢？就是这个状态。

所以，我觉得用 TTFB 描述网络的健康状态并不合理。如果用 Content Download 来描述会更为合理。比如我们上面的这个例子中，那就是 11.75ms 下载了 25317 Bytes 的内容。

Tomcat 上基本上是消耗了处理的所有时间，当然这中间也包括了 MySQL 花费的时间。而前端看到的其他时间就消耗在了网络中。

在这个例子中，主要说明了响应时间怎么一步步拆。当然，如果你是下面这种情况的话，再一个个拆就比较辛苦了，需要换另一种方式。

你肯定想知道每个系统消耗了多长时间，那么我们就需要链路监控工具来拆分时间了。比如像这样来拆分：

从 User 开始，每个服务之间的调用时间，都需要看看时间消耗的监控。这就是时间拆分的一种方式。

其实不管我们用什么样的工具来监控，最终我们想得到的无非是每个环节消耗了多长时间。用日志也好，用链路监控工具也好，甚至抓包都可以。

当我们拆分到了某个环节之后，就有了下一步的动作：构建分析决策树。

六、构建分析决策树

关于分析决策树，我在很多场合也都有提及。

分析决策树，对性能测试分析人员实在是太重要了，是性能分析中不可或缺的一环。它是对架构的梳理，是对系统的梳理，是对问题的梳理，是对查找证据链过程的梳理，是对分析思路的梳理。它起的是纵观全局，高屋建瓴的指导作用。

性能做到了艺术的层级之后，分析决策树就是提炼出来的，可以触类旁通的方法论。

而我要在这里跟你讲的，就是这样的方法论。

应该说，所有的技术行业在面对自己的问题时，都需要有分析决策树。再广而推之的话，所有的问题都要有分析决策树来协助。

通过上面的几个步骤，我们就会知道时间消耗在了哪个节点上。那么之后呢？又当如何？
总要找到根本的原因才可以吧，我画了如下的分析决策图：

从压力工具中，只需要知道 TPS、响应时间和错误率三条曲线，就可以明确判断瓶颈是否存在。再通过分段分层策略，结合监控平台、日志平台，或者其他的实时分析平台，知道架构中的哪个环节有问题，然后再根据更细化的架构图一一拆解下去。

我在这里，以数据库分析和操作系统分析举一下例子。

首先我们看一下数据库分析决策树。

比如针对 RDBMS 中的 MySQL，我们就可以画一个如下的决策树：

由于这里面的内容实在过多，无法一次性展现在这里。我举几个具体的例子给你说明一下。

MySQL 中的索引统计信息有配置值，有状态值。我们要根据具体的结果来判断是否需要增加 key_buffer_size 值的大小。比如这种就无所谓了。

Buffer used     3.00k of   8.00M  %Used:   0.0004

从上面的数据可以看到，key buffer size 就用到了 4%，显然不用增加。
再比如，我们看到这样的数据：

   __Tables_______________________
Open             2000 of 2000    %Cache: 100.00
Opened         15.99M     4.1/s

这就明显有问题了。配置值为 2000 的 Open Table Cache，已经被占满了。显然这里需要分析。但是，看到状态值达到配置值并不意味着我们需要赶紧加大配置值，而是要分析是否合理，再做相应的处理。比如说上面这个，Table 确实打开得多，但是如果我们再对应看下这一条。

Slow 2 s        6.21M     1.6/s

你是不是觉得应该先去处理慢 SQL 的问题了？

关于数据库的我们就不举更多的例子了。在这里只是为了告诉你，在分析决策树的创建过程中，有非常多的相互依赖关系。
然后我们再来看一下操作系统分析决策树，我在这里需要强调一下，操作系统的分析决策树，不可以绕过。

如果你想到操作系统架构图就头大，那么这时候应该觉得有了希望。那就是我觉得操作系统上的问题判断是比较清晰的，所以基于此决策树，每个人都可以做到对操作系统中性能问题的证据链查找。

但是！对嘛，总得有个但是。

对操作系统的理解是个必然的前提。我看过很多人写的操作系统性能分析方面的书籍或资料，发现大部分人把描述计数器的数值当成性能分析。

怎么理解这句话呢？比如说

“CPU 使用率在 TPS 上升的过程中，从 10% 增加到 95%，超过了预期值。” “内存使用率达到 99%，所以是瓶颈点。” “I/O 使用率达到 100%。” 等等。

像这样的描述，在我的性能团队中，一定会被骂回去重写。我要这些描述有什么用？我要的是为什么达到了这样的值，原因在哪？怎么解决？

就像分析决策树中所描述的那样，性能工程师要做的是一步步地细化分析，给出最终的原因。

有人说，如果按这个路子，似乎操作系统的分析并不复杂嘛。大概三五个命令就可以跳到代码层了。是的，对于操作来说，确实不多，但是对于判断来说，那就复杂了。举个例子来说明一下：

看到这样的图，你是不是有种手足无措的感觉？中断能占 40%，sy CPU 也能占 40%。这系统还用干业务的事吗？全干自己的事去了，可见操作系统有问题！你是不是要做这个判断了？

而实际情况是，这个主机上只有一个网卡队列，而请求量又比较大。

所以要解决的是网卡队列的问题，至于怎么解决，那手段就多了。可以换个服务器，可以多加几个队列，可以多接几个节点…

以上只是给出几个性能分析过程中常见的决策树示例。在后续的分析过程实例中，我们将秉承着这种分析思路，一步步地走到瓶颈的面前。

七、场景的比对

为什么要写这一部分呢？因为我看到很多人对瓶颈的判断，并不那么精确，所以想写一下场景比对的建议。

其实简单来说，就一句话：当你觉得系统中哪个环节不行的时候， 又没能力分析它，你可以直接做该环节的增加。

举例来，我们现在有一个如下的架构：

可以得到这样的结果：

从 TPS 曲线中，我们可以明显看到系统是有瓶颈的，但是并不知道在哪里。鉴于系统架构如此简单，我们索性直接在某环节上加上一台服务器，变成这样：

然后得到如下数据：

哟，没好使！
怎么办？再接着加其他节点，我加了更多的 JMeter 机器。

再来看下结果：

真巧，TPS 增加了！

看到了吧，这就是我说的场景比对。

当我们不知道系统中哪个环节存在性能瓶颈时，对架构并不复杂的系统来说，可以使用这样的手段，来做替换法，以快速定位问题。

八、总结

在这一篇中，我说到了瓶颈的精准判断、线程递增的策略、性能衰减的过程、响应时间的拆分、构建分析决策树以及场景的比对，这几个环节，是性能分析过程中非常重要的环节。

从我的经验上来说，这一篇文章可能是我工作十几年的精华所在了。而这里的每一个环节，又有非常多的细分，特别是构建分析决策树这一块，它需要太多的架构知识、系统知识、数据库知识等等。鉴于本文只是想起到一个提纲挈领的作用，所以无法展开描述，希望在后续的篇幅中，我们尽量细致拆解。

思考题
今天的内容虽然有点多，但总的来说，思路比较清晰，理解起来也比较容易。如果你认真学习了今天的内容，不妨思考两个问题，为什么线程递增过程不能断？构建分析决策树的关键是什么？
欢迎你在评论区写下你的思考，我会和你一起交流，也欢迎把这篇文章分享给你的朋友或者同事，一起交流一下。
将学到的知识总结成笔记，方便日后快速查找及复习
22人觉得很赞给文章提建议

---

---

zuozewei
第一个问题：为什么线程递增过程不能断？

这里涉及开篇提到的性能分析能力 ——「趋势分析」。
就像之前提到的一样，分析性能数据趋势需要对一个时间序列数据的分析，一般采用「线性回归分析」算法。
回归分析研究的是多个变量之间的关系。它是一种预测性的建模技术，它研究的是因变量（目标）和自变量（预测器）之间的关系。这种技术通常用于预测分析，时间序列模型以及发现变量之间的因果关系。
假设有 N 个样本点，这里我们可以简单理解线性回归算法就是求一条直线 Y=f(X)，使得各点到这个曲线的距离的绝对值之和最小。
在这种技术中，因变量（TPS）是连续的，自变量（线程数）可以是连续的也可以是离散的，回归线的性质是线性的。

但在性能测试中，由于系统本身的最大 TPS 上限是固定的，即服务端的处理能力（容量）是固定的，如果自变量（线程数）压力过大，那么系统平均处理时间（响应时间）会被拉长。不过这个时候其实瓶颈早就出现了。
所以在场景压测中的自变量（线程数）递增一定需要是连续的，并且在递增的过程中要有梯度的，且场景中的线程递增一定要和因变量（TPS） 的递增有比例关系，且不是突然达到最上限，这样才能准确找出系统的瓶颈点。

第二个问题：构建分析决策树的关键是什么？

决策树基本上就是把我们以前的分析经验总结出来，在做决策树的时候，一般会经历两个阶段：构造和剪枝。
概念简单来说：

• 构造的过程就是选择什么属性作为节点的过程构造的过程就是选择什么属性作为节点的过程；
• 剪枝就是给决策树瘦身，这一步想实现的目标就是，不需要太多的判断，同样可以得到不错的结果。之所以这么做，是为了防止“过拟合”现象的发生。

从性能分析角度来理解：

• 构造：需要根据经验是对架构的梳理，是对系统的梳理，是对问题的梳理，是对查找证据链过程的梳理，是对分析思路的梳理；
• 剪枝：需要对对不同时间序列性能数据的相关性分析，其核心就是要理解各个性能指标的关系，同时进行证据链查找，根据数据的变化来推断得出各种结论，比如故障判别、根因分析等。
  2019-12-27

小呀么小二郎
今天的内容有点多，写了份总结，正好梳理一下思路

本节内容主要讲了性能分析思路。从6个方面来分析：

首先，要准确的判断瓶颈点。通过什么来判断呢？TPS曲线。TPS曲线能够告诉我们系统是否有瓶颈，以及瓶颈是否与压力有关。为什么不需要响应时间曲线来判断呢？因为响应时间主要是用来判断业务快慢的。

其次，我们要确定我们设置的性能场景是正确的，线程是逐渐递增的，而不应该一上来就上几百个线程。原因：1、直接上几百个线程不符合一般情况下的真实场景。2、即使是秒杀场景也有个“数据预热”的过程（我的理解，数据预热跟线程递增应该差不多，有一个由小到大逐渐增加的过程）3、对于TPS已经到达上限的系统来说，除了响应时间的增加，没有其他作用。

再次，我们要拥有能判断性能衰减的能力。如何判断？分段计算每线程每秒的TPS，如果这个数值开始变少，那么性能瓶颈就出现了。此时再随着线程的增加，性能逐渐衰减，TPS逐渐达到上限。

然后，我们知道性能开始衰减了，那么是什么原因导致的衰减？此时就需要对响应时间进行拆分，拆分的前提需要熟悉系统的架构，拆分的目的是要知道每个环节消耗的时间，拆分的方法可以通过日志，可以通过监控工具，也可以通过抓包（抓包应该需要和日志配合吧？以老师的例子来说，能抓到tomcat的请求和响应时间吗？我感觉不能……）

再然后，最重要的地方到了，我们要逐步构建自己的分析决策树。随着性能分析经验的累加，我们需要整理并总结每次遇到的性能问题以及相对应的解决方法，同时我们还要不断扩充自己的知识库：系统架构、操作系统、数据库、缓存、路由等等，并将这些知识与经验结合起来。重新梳理，由大到小，由宏观到细节，去画出自己的分析决策树。

最后一点感觉是对第一条的补充，而且应该也是对小白（比如我）的一个提点，当我们刚开始进行性能分析，没有思路的时候，那就可以通过这种替换法来帮助我们快速定位问题。当然，这种方法比较适合简单的系统，如果系统很复杂，这样替换不一定方便了。

这节课很重要，但是像我这种没有实际分析调优经验的小白来说，看懂跟理解好像还是缺少了实际操作在里头。这篇大概需要练习后再反复的回看。

今天的思考题答案基本写在上面的总结里了，如果有理解不正确的地方请老师指正。最后，感谢老师把宝贵的经验分享给我们，老师辛苦啦！
作者回复: 写的太好了。你是最认真的一个！

2020-03-16

吴小喵
看到构建分析决策树就吓死了，数据库的知识，操作系统的知识都不懂啊，o(╥﹏╥)o
作者回复: 慢慢来。反正不是吓死就是累死。

2019-12-27

rainbowzhouj
第一个问题：不能断的原因是保证在测试过程中资源分配的合理性，减少偏差，便于分析出当前环境中的性能瓶颈点。否则断开后系统动态资源会重新分配，造成分析偏差。
第二个问题：构建分析决策树的关键好比如何画一棵树。先确定主干（主要流程），然后添枝干（组成部分），最后画树叶（定位问题）。从上到下，从左到右，拆分…

总的体会感觉给我这种测试野路子出身的工程师，又梳理了一遍如何定位问题的方法。让我对之前的工作实践中地操作有了进一步地理解。并且重新审视目前我所处的阶段：操作能力待加强。感谢老师，读完文章感到意犹未尽，希望在后续的课程能更加精彩。
作者回复: 多谢肯定。
一看评论就是练家子出身的。多做总结，就会有更多的收获。

2019-12-27

Geek_65c0a2
这节课我也期待了好久。高老师写的字数多点，总感觉不够看
作者回复: 编辑小美女说我文章写太长了。

2019-12-27

hou
请问老师，递增经验中， 为什么响应时间少，递增幅度小呢？
作者回复: 响应时间小的话，每个线程产生的TPS就高呀。
所以线程增加的幅度就要小一点。如果线程增加多了，因为单TPS高所以压力增加的就快，这样不得于产生明显的性能梯度用来分析。

2020-03-04

土耳其小土豆
看高老师的文件，感觉都能看懂，但是高老师的问题，我却回答不了，特别是第一个问题。
作者回复: 练。你还年轻。

2019-12-30

那片海
高老师有3个问题问下：
1、 你给了一个 性能场景递增的经验值，是 基于响应值 每秒增加的 线程数，最终达到目标线程数？
2、 线程不能断，如果是测试稳定性场景 也需要这样梯度加压吗 可以直接1s内加压到最大线程数？
3、 在jmeter工具中，梯度加压 是使用默认的线程组 ramp up设置呢， 还是安装插件后使用Stepping Thread Group 和 concurrency Thread Group 设置 ？
作者回复: 1. 是的。不过这个过程要多次调整。
2. 稳定性测试场景关注点不在递增那一阶段上，所以递增不递增都可以，就算递增用几分钟，也不影响稳定性测试整体场景的持续时间。
3. 这个都可以，取决于项目中要求的细致不细致了。装了插件我觉得会好一些，控制的细致。

2020-03-06

qiaotaoli
老师，再问一下，你文中发的递增经验值，后面的1-3指的是，比如第一个阶梯并发数是10，第二个阶梯并发数变为20-40，对么？另外，为什么响应时间越大后，并发幅度也变大呢？是因为响应时间变大后，并发幅度变化不大，可能看不出太大变化么？
作者回复: 响应时间越短，并发递增越小。

2020-01-06

suke
关于线程递增的策略，基本几千的并发数就需要多台jmeter去分布式的压了，当压测事件持续几个小时的时候最后生成的压测报告都很大都有几个g，有很大概率生成报告失败，对于这个问题老师有什么好的实践经验么
作者回复: Jmeter+influxdb+grafana实时输出。

2020-03-09

筱の简單
1、为什么线程递增过程不能断？
因为场景中的线程递增且连续符合业务实际场景，可以较好的判断系统瓶颈。

2、构建分析决策树的关键是什么？
构建分析决策树的关键是对架构的梳理，对系统的梳理，对问题的梳理，对查找证据链过程的梳理，对分析思路的梳理。它起的是纵观全局，高屋建瓴的指导作用。
作者回复: 理解的很对！

2020-02-19

SHATAN CLASS
老师好，这篇我看了3遍了，非常喜欢您的课程，觉得您给到的观念和层次感都比较足。
但是其实在很多实际项目中寻在几个问题：
1、性能需求都不明确；
2、测试人员对系统的架构不熟悉，那就更不用谈什么性能分析和调优了。
针对这两点，老师有什么更好的解决方案吗？
作者回复: 1. 只有找相关的人去沟通。或者拿生产数据统计分析。
2. 这个只能学习了，没啥捷径。

2021-03-12

Geek_fbce88
线程数是100,平均响应时间是0.2秒，没有设置几个点等，请问并发是500吗？因为一秒钟发送了500个请求
作者回复: 对的。

2020-09-14

hou
老师，前面我们约定了性能指标用TPS来描述。但是在性能衰减的例子中，图1是请求数，您在描述中把请求数描述成TPS，这个让我很难理解。这里为什么请求数就成了TPS呢？
作者回复: 在整个专栏中，我都是用TPS这个概念来描述压力的。没有用请求数来描述。
请求数和事务的关系就是，当只有一个请求时，那就不用定义事务了，直接可以把请求数每秒当成TPS。

2020-03-04

hou
请求时间消耗了 28ms，响应时间消耗了 27ms。nginx接到请求的刹那，记录下请求时间，这是一个时间点，消耗28ms一般是在做什么呢，不应该只是一个时间点吗
作者回复: 不是。请求时间是包括了进来和出去的时间，响应是记录的后端的时间。所以请求时间其实是一个时间段，不是时间点。

2020-02-29

伊森
高老师，请问本节展示的四幅图：请求每秒、响应时间、线程数和请求/线程，都是jmeter自带的那个HTML报告生成的吗？如果是我没有找到请求每秒和请求/线程这两幅图，另外响应时间和线程数两幅图分别是对应的 Response Times Over Time和Active Threads Over Time吗？请帮忙确认一下在哪里找到这4幅图吗？谢谢
作者回复: 是我拿原始数据用excel生成的。

2020-02-09

学员141
老师，一般哪些配置会影响抖动呢？
文章中“上升的过程中有几次抖动，这个抖动到后面变大了，也变频繁了，如果这是必然出现的抖动，那也是配置问题”
作者回复: 最大最小空闲线程数之类的就会影响 。

2021-12-03

Geek_23f5cd
老师你好，请问下如何通过日志中记录的时间计算服务器的处理时间的，比如tomcat服务器上记录的请求时间的 28ms，后端响应时间的 28ms，那么tomcat服务总共的耗时是多少？具体怎么计算的？？这里没看明白
作者回复: 这说明这个服务本身没有耗ms级的时间。请求时间包括响应时间。

2021-11-15

学员141
老师，分钟和秒为力度是针对那个方面或者指标来说的？没有看懂
作者回复: 对所有曲线都可以区分分钟和秒。分钟看趋势。秒看毛刺。

2021-09-07

徐传龙
第一个问题： Nignx配置的requestt​ime和upstream_response_time。。requesttime记录的是用户发送请求到Nginx–>tomcat最终到DB的总共时间吗？
14.131.17.129 - - [09/Dec/2019:08:08:09 +0000] “GET / HTTP/1.1” 200 25317 0.028 0.028

第二个问题，tomcat记录的这个28ms、27ms又是哪些节点的时间？
172.18.0.1 - - [09/Dec/2019:08:08:09 +0000] “GET / HTTP/1.1” 200 25317 28 27 http-nio-8080-exec-1
作者回复: 1，是的。
2，也是请求和响应时间，包括它的后端。

2021-06-22

相看两不厌
看了3遍，总结+疑问，希望高老师能回复

1. 判断是否存在瓶颈
   通过tps曲线可得出的常见结论：压力越大，tps增幅越小，直至为零，存在瓶颈：tps规律性波动，压力只是将现象放大，存在瓶颈
   通过响应时间曲线可得出的常见结论：随着压力增大，响应时间也增大，存在瓶颈
   疑问：工作中经常是做高老师所谓的性能验证工作，通常测试环境操作系统相关配置就是和现网保持一致，尽量去测出应用和中间件配置的问题。经常会有疑问就是，接口达不到指标，不知道是不是在当前操作系统配置下，接口本身就是这样的能力了，不好判断是否接口存在问题。
2. 线程递增的策略
   场景中的线程递增一定要连续，这样更符合真实场景，可能也给了系统预热的时间
   工作中我一直都是按给定的并发数直接去压，看能否达到tps指标。以后我还是用梯度方式，可以看出趋势变化。
   疑问：老师说随着响应时间，可以设置不同的梯度。我的理解是都可以按1平稳增加吧
3. 性能衰减的过程
   老师通过例子展示的每个线程请求数降低，性能瓶颈就已经出现，其实还是响应时间增大了导致；但是瓶颈出现，并不意味着服务器的处理能力降低，相反，在并发数和响应时间达到某个点之前，处理能力就一直是增加的，事实就是在性能不断衰减的过程中，TPS达到上限。
4. 响应时间的拆分
   可以通过日志打印请求响应时间、前端通过TTFB、复杂调用可以依靠调用链将点到点的时间拆分出来
   工作中是绕过nginx，直接请求微服务接口进行压测，使用的工具就是调用链，真的非常方便
5. 构建分析决策树
   这块感觉是重中之重，同时也是难上加难，我的理解是构建分析决策树是将可能影响性能的模块列出来后，再细分其下的属性、配置等，针对测试数据来判断是否为问题点。体现了性能工程师全面又专业的水准。
   自己现在还差的很多，但是老师拿mysql举例还是给我实际工作有很大帮助。我工作中在msyql中就是加索引这一点，从来没像老师这样具体分析。后面详细学习下应用到工作中
6. 场景的比对
   疑问：当5个jmeter，1台服务器时已经出现瓶颈，此时压力肯定够大了。但是添加2台服务器后，同样添加到10个jmeter，压力和服务器都在增加，TPS增加也是正常的啊。还是没能找出开始时的瓶颈所在。这节确实不理解。

总的来说，这篇文章在思路上确实让我学习到很多。希望后面能跟老师学习到具体的细节操作，才能在实战中游刃有余。
作者回复: 看来这位同学是认真了。我也得认真回答下。
1，在固定的硬件配置下，要想知道接口有没有问题，就需要判断下接口响应时间的消耗，像apm、jvirsualvm,、arthas等工具都可以帮助你。这个判断是综合的判断，还要看硬件资源下是否已达到计算能力的最大值。再细节的就是要看方法级时间消耗是否合理。
2，按1平稳增加是可以的，只是在有些场景中，按1增加会需要比较长的时间，所以有时为了节省时间，我会增加的快一点。如果你有足够的时候，可以一直按1增加。这个没问题。
3. 理解正确！
4. 看来是真的实践了，这也是专栏的价值所在呀，能落地。哈哈。
5. 有思路就不怕落不了地。加油。不管是什么数据库，这思路都会有用。
6. 我写的应该在加了一台服务器之后，tps没有增加，所以才考虑增加多个jmeter的。这时压力有增加，就说明之前的压力不够。

我也觉得这篇是最有价值的，他的作用足以起到提纲挈领的作用。有疑问还可以接着问哈。

2020-11-11

Geek_coral
老师课件中展示的这些图，对于分析和性能测试报告的生成都很有帮助，比如TPS视图，响应时间视图，曲线等。请问是使用什么工具生成的呢
作者回复: 有的是jmeter的dashboard，也就是生成的report，有的是jmeter插件。

2020-10-14

chailyn
有个疑问，请教老师，线程图是一直递增的，但是文章中又说到线程要依次递增，对比TPS来寻求性能瓶颈与最大TPS，所以到底压测时斜线递增好还是阶梯型递增好呢？
作者回复: 这是一样的意思。两种方式都可以，只是为了找到最大TPS。

2020-08-18

凯
厉害，厉害，厉害，厉害，受益匪浅呀，
作者回复: 多谢支持。

2020-05-22

月亮和六便士
高老师，1.数据库的时间拆分怎么做？比如 网络，应用消耗时间，怎么能知道SQL语句消耗了时间？2. 如果响应时间是300毫秒，慢SQL需要调整到100毫秒么？如果这时候慢SQL是一秒，那且不是永远没有慢SQL了吗？
作者回复: 1. 不同的DB中手法不太相同，但大同小异。比如说执行计划。
2. 那必须要调小呀。

2020-04-12

骆俊
Tomcat 上基本上是消耗了处理的所有时间，当然这中间也包括了 MySQL 花费的时间。而前端看到的其他时间就消耗在了网络中。——怎么看出来花费在tomcat上而不是nginx上的
作者回复: 如果nginx上的时间长，同时tomcat上的时间和nginx中差不多，那就是tomcat的花费了。
如果nginx上时间长，而tomcat时间短，那就是nginx或nginx-tomcat间的网络。而网络的时延是可以通过网络工具分析的，也可以单独测试网络传输时延。

2020-03-21

你比昨天快乐
再次来看收获又不一样了。对于秒杀类的场景，我们前期一定是做好了系统预热的工作的，请问这句话中怎么理解系统预热，如何预热？
作者回复: 举例来说，redis中在执行前先加载数据进去。像id之类的提前生成。

2020-03-17

立兵
1、为什么线程递增过程不能断？
连接的趋势图才能看到清晰的问题点（拐点、毛刺、抖动）。
2、构建分析决策树的关键是什么？
对构架和操作系统（某种意义上也是构架）的理解 ，找到影响性能的组件或网元
作者回复: 理解正确。

2020-03-04

黄玲玲
求老师帮忙解答下，响应时间是通过配置什么，或者什么具体的命令来查看的
作者回复: 在nginx中有request_time 和upstream_response_time可以配置。
在tomcat中有%D和%F可以配置。
如果是自己的应用，就得看日志中有没有打印了。
如果通过链路级的监控工具，也可以直接看到接口级的响应时间。

2020-02-16

夜空中最亮的星
果然是倾囊相授，谢谢老师xxe
作者回复: 多谢支持。

2020-01-15

songyy
思考题

• 为什么线程递增过程不能断：因为中断的地方，可能会出现拐点。断了就看不到了
  构建分析决策树的关键是什么：关键是对要分析系统的理解
  作者回复: 第一点：我不建议用拐点来描述，而是应该用抖动来描述会更好。哈哈。

第二点：非常对。

2020-01-11

Wang
高老师，近期在验证tomcat 8 在NIO和APR两种模式下的性能差异。理论上APR在高并发的情况下性能更好一些，但是我验证的结果却是NIO的性能更好（同样的并发线程数，NIO模式的吞吐量更高，相同的吞吐量，系统的资源利用率相差并不大）。代码中只是设置了等待20或200ms然后打印输出字符，无任何逻辑。有些迷茫求高老师帮忙分析一下，多谢
作者回复: 虽然网上有很多写APR比NIO性能要好。但这个观点基本上是错的。
因为NIO、AIO、APR各适用于不同的应用场景。并且，也并不一定APR就一定比NIO、AIO性能高了。
所以你的结果应该是对的。不用迷茫。

2020-01-09

qiaotaoli
老师，问3个问题，望能回复，先谢谢了。
问题1:文中提到“压力策略不会改变系统的最大TPS”，这个说法是不是有些绝对了呢？比如一开始就发起很大并发数让cpu，内存使用率都非常高，或者可能出现了数据库死锁等问题，我理解这种情况下系统的最大TPS比逐步递增压出来的最大TPS小，这个理解正确么？
问题2:“文中提到压测时要预热”，预热指的就是并发用户数从小到大逐步递增，对么？
问题3:“文中提到为了让性能瓶颈更显著，需要压到响应时间变长直到需要被拆分”的时候，这个具体是什么时候呢？因为并发数增加后，响应时间肯定会慢慢变长。
作者回复: 1，一开始就加大压力的场景只会让系统忙于分配资源。这个场景就不合理。如果这样做，tps是有可能低的。
2，递增是一种预热的方式。还有其他手段，比如把数据先加载到redis里去等等。
3，这个没有特定的什么时候。只有根据场景具体判断了。

2020-01-06

金面王朝
老师，在做响应时间决策树之前，需要监控微服务的响应时间消耗，有没有开源工具或其他工具推荐呢？
作者回复: pinpoing/skywalking/Zipkin/CAT，都是。

2019-12-29

LensAclrtn
老师,关于性能场景递增经验值的问题我不是很懂, 响应时间越短代表系统性能应该越好,为什么反而用更小的线程递增幅度呢,这样不是要很久才能达到最大tps瓶颈吗? 这里的响应时间的不同是为了突出不同系统性能差异还是架构复杂度差异呢?
作者回复: 在场景中实际去操作一下就会理解了。
响应时间短，单个线程的TPS就会高，如果这时线程加多了，TPS就涨的幅度特别大。不利于查看TPS的增加趋势。

2019-12-29

村夫
第一个问题，首先这样做肯定是更符合真实的业务场景，线程不断递增也有利于服务器预热。但是预热的目的是为了防止直接把服务器压死吗，就跟冬季开车前需要预热一样？这个不太清楚。而且老师说的线程递增场景的例子，当响应时间小于50毫秒，建议一个线程一个线程的往上递增。这个50毫秒我是不是要先一个线程跑个一分钟或者迭代100次来得出呢？还有就是假如真是小于50毫秒，我设计场景的时候初始线程应该是多少呢？
第二个问题，如何构建分析决策树？
我认为首先要有这样的意识吧，胸有成竹吗，肯定要先有这样的理念，然后要学会分层以及从宏观到微观。老师特别强调要熟悉应用架构，这个就是我理解的先宏观的知道有哪些东西，因为压力工具能提供给我们的东西很少，我们要找到证据链必须要全局了解被压测应用，这样我们就可以根据压力工具提供的一些数据来分层的找原因，找证据。再有就是要扩大自己的知识背景以及视野，了解监控工具等等。
想法比较乱，思路也不太顺，请老师点评，谢谢。
作者回复: 1. 在后面的场景篇会有详细的描述。先做基准场景，再做容量场景。在基准和容量中都是递增的方式。
初始化线程的多少取决于系统的承受能力，通常我会大幅度跳跃的线程数来评估系统的最大容量，然后再决定初始线程是多少。
2. 说的非常对！有这个理念就可以出师一半了。哈。

2019-12-28

Geek_f93234
第一个例子中不太明白：
针对这个结论：
“但是至少我们可以有一个非常明确的判断，那就是瓶颈在第二个压力阶梯上已经出现了。因为响应时间增加了，TPS 增加得却没有那么多，到第三个阶梯时，显然增加的 TPS 更少了，响应时间也在不断地增加，所以，性能瓶颈在加剧，越往后就越明显。”
从图中可以看出如下：
序号 tps Restime
1 500 4
2 1000(压力2) 4.5(时间1)
3 1500(压力3) 5（时间1.25）
4 2000（压力4） 6（时间1.5）
响应时间变化的比较慢，压力变化的更快一些，请老师详细分析下这个结论是怎么得出来的
作者回复: 是这样的。
第一个阶梯是500tps。如果性能没有衰减。
第二个阶梯应该到1000左右，而实际的结果是没到1000，只有900左右。增幅400tps。
第三个阶梯应该到1500左右，但实际的也没到。只到了1200左右。 增幅300tps。

而在这个过程中，响应时间是不断增加的。所以性能瓶颈是明显已经出现了，并且越往后越大。

2019-12-28

律飛
思考题一，为什么线程递增过程不能断？
1.线程递增更接近真实的业务场景。性能测试的目的是为真实业务场景提供依据，提供信心，如果不能反映真实业务场景，这种测试跟没做又有什么区别呢？
2.为理解数据提供更多的信息。更多的数据信息肯定有利于更好的理解数据，防止理解偏差。
3.更多的数据信息有利于更好地把握趋势，有利于分析，更为精准地发现问题，为调优提供依据。
4.性价比最高，不仅有经济上的，也是时间上的。可以用更少的投入更少的时间获得更多的信息。
思考题二，构建分析决策树的关键是什么？
首先是要有全局观，要从架构系统角度全面地去梳理发现问题，其次是要有方法论，不能眉毛胡子一把抓，不能像无头苍蝇乱窜。而这就要求我们要进行知识的积累、经验的积累。
台上一分钟，台下十年功呀！感谢老师精彩的讲解！谢谢老师的倾囊相授！希望老师能放更多的分析决策树，让我们能在老师的树荫下乘凉。这次课也明显地看到了巨大的差距，希望老师可以为我们推荐个书单，方便我们练好台下功。
作者回复: 看到这评价，确实是认真看了内容了。理解的也很正确。

书单，我好像在其他的评论中回复了。这个比较难推荐。我的建议就是一个组件找一本优化的书完整的看完。像OS、DB、NET、代码等，各看一本，这个我没办法一一推荐。取决于各自的工作环境，工作中用什么就先看什么。其他的要看自己想学哪个。

2019-12-27

月亮和六便士
老师，我想问一下，假如一个系统存在瓶颈，但是又不明显，除了讲的方法外，还有什么办法？我想更进一步深入排查，一般的排查思路是什么？顺序是什么？
作者回复: 对于不明显的瓶颈，就想办法让它明显起来。基于这个目的，你可以增加压力，让响应时间增加，在瓶颈点上，肯定会是时间消耗的快的。
当响应时间增加了之后，再通过分段拆响应时间的方式就可以了。

2019-12-27

大拇哥
做性能测试的我，对老师说的有着切身的感受，虽然此前也遇到老师所说的这些点，但从来没有像现在这样清晰，感谢~
作者回复: 多谢肯定。我会再接再励。

2019-12-27

小妖
这些数据图都是从哪里监控到的哦？
作者回复: 图来源各有不同，没有固定的监控工具可以做到。

2022-02-24

Cathy
能力阶梯：
1、工具操作；
2、数值理解；
3、趋势分析；
4、调优。

性能分析思路：
1、判断瓶颈(清晰的弧度，而非清晰的拐点)；
2、线程递增策略（0～50ms_100ms200ms~500ms; 1₃5~10）；
3、性能衰减过程（每线程发出的请求数变化趋势）；
4、响应时间拆分；
5、构建分析决策树；
6、场景的比对。
作者回复: 想的对！

2022-01-25

Geek_admin
你好，有一个疑惑
在第一块讲拐点的地方，我们是只根据图片来判断出这个系统有瓶颈
但在实际中，判断系统是否存在瓶颈是否需要结合实际需求来下结论呢？
作者回复: 这里判断的是技术的瓶颈。如果是有业务的需求低于当前的容量，可以下结论说满足上线的容量需求，但明显的性能瓶颈还是存在的。

2022-01-22

冒冒
我就是文中说的没有操作功底的小白，希望高老师能有更多的关于操作功底的文章；还想学习一些关于怎么分析分布式系统的文章
作者回复: 后面的专栏都是分布式系统。

2021-12-09

Tomcat Shao
碰到微服务多，或者cp多，也可以把认为是瓶颈的服务用nginx打个测试桩验证
作者回复: 没看懂这个是啥问题。微服务中现在不是多用Mock吗？

2021-11-27

耿强
每个也场景或者展示的图片分别用到了什么工具能说一下吗
作者回复: 性能的工具都是用的jmeter。还有就是用Excel整理的图。似乎也没有什么其他工具了。

2021-11-08

BMB
我认为系统拐点应该在比较稳定的期间给出，图片1中重要的问题是后面几个梯度的结果波动严重，我们要首先排查以及解决波动问题，在一个波动的结果中我们确实没法确定拐点位置。
作者回复: 应该确定的是最大稳定tps，而不是拐不拐。

2021-10-25

碎碎念
第一遍，打卡，但是之前学过一点，但是对于操作系统，中间件等不熟，不怎么会做分析哪里有问题，下次动手的时候再回归读一遍，现在收获：
1、设置场景持续递增
2、等价对比照瓶颈
3、响应时间分段
4、线程设置的梯度大小
5、关注tps曲线，并不只看时间曲线，一位时间是指衡量响应的快慢，tps才是反应系统处理的大小是否达到瓶颈
作者回复: 总结总是对的。

2021-10-06

zwm
第二遍回来看了，不一样的收获
作者回复: 我也回来看几遍了，自己写过的也不一定会。

2021-09-07

学员141
1.上面说的粒度是什么粒度？截图的表格，一个分钟粒度，一个是秒粒度，不是很明白说的啥；
2.我们有个接口A，我单独调用，响应是165ms左右，tps为6.1/s，如果1个线程连着调用两次这个接口A，但是入参不一样 ,这样执行平均响应是129ms左右，但tps为1.6/s，当然这两个不同入参单独调用都能是响应是165ms左右，tps为6.1/s,不明白什么原因，麻烦老师帮忙分析下
3.第二点中的场景变成：2个线程调用这个接口，这样跑出来的tps就翻倍为13.7/s，响应时间是144ms，这个应该是缓存的原因吧？
作者回复: 1. 粒度就是计算数据的周期。秒和分钟就是不同的粒度呀。为了看细的数据就要用秒级，如果要看趋势，看分钟就可以。
2. 没看懂这个描述。你这个T是个什么？每次调用接口是一个T吗？那为什么响应时间低了tps也低了？不应该tps高吗？
3. 看起来这个才是正常的，和缓存无关。一个线程是串行调用，两线程是并行调用，那翻倍就是合理的呀。

2021-08-13

懒猫
性能不就是服务器处理能力也就是TPS吗？为什么说TPS还在缓慢增加，但是性能开始衰减呢？
作者回复: 只要响应时间变长了，用户的感受就是性能差了。

2021-07-06

万历十五年
瓶颈：每线程每秒请求数下降，即出现性能瓶颈；为了使问题更明显，继续加压，直到响应时间开始明显增大
加压：线程持续递增是为了看tps的趋势
作者回复: 理解正确。

2021-06-25

Geek_我爱学习
能力有限看不懂了
2021-06-24

0909
构建分析决策树需要扎实的计算机基础，不是一朝一夕可以搞定的。加油吧
作者回复: 努力努力，过几年就有基础了。

2021-06-07

孙善明[花开堪折枝]
场景一的描述我觉得不是很合适，执行压测过程中应该也是从低到高开始的，而不是开始就是400，所以这个应该也会更早的发现tps已经不增加了
作者回复: 可不。这描述不就是要说场景一是不对的嘛。哈哈。

2021-05-15

jy
老师，关于时间拆解，
1、上面非微服务例子，如何拆分tomcat的时间和mysql的时间？
2、非微服务可以用skywalking么？能看到mysql的单独耗时么？
谢谢
作者回复: 1. 本文中不是有写吗。nginx和tomcat都是配置参数就可以拆解时间。mysql的时间直接设置慢日志就行。
2. java的都可以。

2021-04-20

Mingyan

“Buffer used 3.00k of 8.00M %Used: 0.04

从上面的数据可以看到，key buffer size 就用到了 4%，显然不用增加。”

这里是不是已经变成百分数了吧？我理解那就是0.04%，您文中说4%，我不太理解。
作者回复: 说的对。这里手误了，我改一下。联系我微信，发红包感谢。Zee_7D

2021-04-19

Mingyan
本文里的分析图如果用loadrunner来设置vusers数，阶梯增长 但是pacing设置1s，这样的话达不到文章里的图那样吧？
作者回复: pacing是迭代之间的停顿时间，和ramp-up不是一回事。

2021-03-30

jy
这里给出我做性能场景递增的经验值。。
比如，200-500ms，5-10，这个5-10个线程，是每分钟增加还是多少时间？
作者回复: 我通常会设置1-5分钟，根据具体的曲线来判断。

2021-03-02

闲鱼超人
问题：为什么线程递增的过程不能断？
当压力逐步上升时，理想状况下得到连续的性能曲线，有利于分析瓶颈出现的时间点。

问题：构建分析决策树的关键是什么？
构建分析决策树关键是能对服务处理链路的逻辑有清晰的理解认识，在这个清晰的逻辑下，去构建你的分析决策树，参考监控指标，去分析哪个环节出了问题，为什么会有问题。
作者回复: 理解没毛病。

2021-02-20

Geek_88dbc9
高老师：场景 2 使用了递增的策略，在每个阶梯递增的过程中，出现了抖动，这就明显是系统设置的不合理导致的。设置不合理，有两种可能性：1. 资源的动态分配不合理，像后端线程池、内存、缓存等等；2. 数据没有预热。
请问 数据预热是指什么？在哪些场景下需要？
作者回复: 像秒杀场景就需要哇。

2021-02-02

Geek_6a9aeb
老师，瓶颈和压力有没有关系这一点，如果有关系 那不是接下来增加压力让响应时间增加拆分分析？ 如果跟压力没有关系，那么接下来又从哪里着手分析呢？
作者回复: 压力跟瓶颈肯定有关系呀。压力增加不增加，只要有瓶颈了都能分析。

2021-01-23

小鱼儿
不断学习中，刚开始没有耐心的去细想，到现在觉得老师的每一段话都可以细究，能学到东西。现在我觉得我之前测的都是什么东西
作者回复: 所以我觉得这一篇才是全专栏的重点。哈哈。
都是经验的总结呀。
知不足而后进，永远不迟。

2021-01-19

蔚来懿
老师，看了留言的的一条疑问，同样有问题，
疑问：当5个jmeter，1台服务器时已经出现瓶颈，此时压力肯定够大了。但是添加2台服务器后，同样添加到10个jmeter，压力和服务器都在增加，TPS增加也是正常的啊。还是没能找出开始时的瓶颈所在。
答复：我写的应该在加了一台服务器之后，tps没有增加，所以才考虑增加多个jmeter的。这时压力有增加，就说明之前的压力不够。
我的疑问：增加了一台server，TPS没有增加，说明压力不够，增加jmeter，这个么有问题，但是确实没有分析瓶颈是什么，只能说明这个系统可以横向扩展去提升系统性能。
作者回复: 这一段不是为了说明如何找具体的性能瓶颈点。而是为了说明大块的分段测试对比出哪一段有问题。

2021-01-02

蔚来懿
老师，请问下服务架构和部署同样的情况下，接口1和接口2处理逻辑类似，但是压测的情况不同，1个jmeter压测结果接口1TPS可以达到1万，接口2只能达到5000。在压测接口2的时候，增加jmeter机器个数，TPS在增加，随着压力机的增加，TPS阶梯上升。在整个压测过程中，应用服务器和压力服务器的资源利用率都很低，开发认为是压力机的原因，但是另外一个接口一个压力机就能达到一万，这种情况如何分析呢？
作者回复: 你这样描述我很判断。可以微信上找我，发数据给我看。

2021-01-02

alley
分析思路很好，就是自己太小白，不会落地。期待更多的实战课程
作者回复: 都在后面。

2020-12-12

David.cui
我经常遇到的一个问题是甲方录制好一个脚本用ld.跑压测，看哪个数据库的tps指标高就认为是那个数据库产品更快。总感觉和您讲的对不上啊
作者回复: 有没有具体数据可以提供给我分析下？

2020-12-03

Geek_e5c37b
线程数就是用户数，递增的策略每次测试执行时间怎么算呢？要持续多久呢
作者回复: 压力线程数不是用户数。
每个系统采用的递增策略都不一样。针对不同的场景也不一样。持续时间也要根据场景来。
这个在每个项目中都要通过测试才能知道。

2020-10-21

路客
最后场景那个例子没有看懂，jmeter增加后，tps增加了代表了什么呢？老师可以帮解答下么
作者回复: 说明压力机不够使。

2020-10-05

独行客
老师，问你一个问题，一个50量级的系统，针对登陆注册以及下单聊天，TPS得达到多少才能支撑系统正常运行
作者回复: 这个？？需求有点模糊。可以联系我微信详细讨论。Zee_7D

2020-09-22

qiaotaoli
高老师，我刚刚提的问题不用回复我哈，是我自己么有装插件。我找到如何设置了。
2020-08-25

qiaotaoli
高楼老师问一下，上面的场景二线程图中，我看线程从每次递增20，然后持续一段时间又递增20。但jmeter的并发线程那里就只有Number of Thread和Ramp-up两个参数，你是如何设置才能出现这样的线程递增方式呢？
作者回复: 有插件。

2020-08-25

-_-
虽然第一次看不是很懂，但是感觉到满满的干货，赞一个
作者回复: 相当的干。

2020-08-06

小破鸟儿
回头看的第三遍，感觉每看一遍都有收获，有些总结性的话挺有意义的。
作者回复: 多谢支持。

2020-07-22

薄荷微凉ζ
老师，你上面有说递增的经验值，比如50ms的时候，经验值是1-2这个1到2说的是递增倍数还是线程数？，比如我起始线程数是10,那第二个阶段是加到20吗？还是说加到11,或者12？
作者回复: 是线程数。起始线程数也应该是1-2.

2020-07-17

牺牲
这节课内容太多了，多看几遍
作者回复: 全是精华。

2020-06-14

钱
想象自己是一次请求之旅的导游，带着字节流的队伍穿过路由器的河流闯关网络世界的森林进入某个王国见过国王和重臣，然后在同样的一路返回，遇见了什么怪物战斗花费了多久时间战斗。
如果对于计算机软硬件各种原理都了解，了解的越多越深这种想象就会越细致具体，那定位问题也就越快越准。
目前对我来讲网络通信这一段路程还不能想象的挺好，需要加强。
作者回复: 想像力很丰富。挺好。

2020-05-19

郑颖
老师，有个问题 文中有个图写了线程递增的规则，只写了递增幅度，但多久递增一次呢
作者回复: 根据响应时间，我们会在每个场景中都设置为不同的递增时间间隔。所以这个并不固定。

2020-05-09

summer清
老师:最近遇到一个问题一直不知道原因，麻烦帮我指点下
jmeter运行后部分请求失败，报错: commection reset ，上网查询方法都有过尝试，并没有明白问题原因，也没有解决
感觉并发数也不大，大概300多会出现错误，一旦出现这个错误，再用小的并发就必然会有一两个请求出现连接重置
感觉跟运行时设置调度器时间也有点关系，每次好像到了设置时间总有一些线程停不下来，然后就会出这个错
作者回复: 这个要看一下服务端报的什么错了。

2020-05-07

黄莉薇
场景 2 使用了递增的策略，在每个阶梯递增的过程中，出现了抖动，这就明显是系统设置的不合理导致的。设置不合理，有两种可能性：1. 资源的动态分配不合理，像后端线程池、内存、缓存等等；2. 数据没有预热。
老师，这句话不太懂是什么意思
作者回复: 就是当配置不合理的时候，才会出现曲线的抖动。

2020-04-25

月亮和六便士
高老师 如果jmeter中 rt很短，还需要做时间拆分么？比如rt 30毫秒，还有假如链路很长，一个线程rt 3秒，这种固定消耗的时间需要做时间拆分么？
作者回复: 如果你觉得可以接受就可以不用拆。如果你觉得不能接受，要分析性能瓶颈在哪，就要拆。

2020-04-12

sundy
场景中的线程递增一定是连续的，并且在递增的过程中也是有梯度的。

请问老师 这里的梯度指的是持续时间吗
作者回复: 梯度是ramp-up的过程。我理解你说的持续时间是duration吧。

2020-04-11

王春丽
老师，您这用的是什么啊？
作者回复: 往后看都有工具的说明。

2020-03-30

Geek_237b86
高老师请教个问题，300万用户,最高并发量大概50-70万,如何确定需要几台服务器? 服务器内存128G,8个4核CPU,主频2.6GHz
作者回复: 这显然是个没法回答的问题。不测试分析就不会知道答案。

2020-03-27

吕作晶
其实是不是任何一个一个唯独上tps降啦，就说明到了性能瓶颈！
作者回复: 可以这么说。只要出现性能瓶颈后，业务不会大幅度下滑。就是好的系统。

2020-03-22

jiangjing
讲的最好的性能测试理论 。值得反复阅读品味
作者回复: 多谢鼓励！共同探讨。

2020-03-19

kubxy
老师，请教您一下，关于nginx日志和tomcat日志中记录的请求时间和响应时间的理解。
查看了官网以及网络上的一些文档，对它们的理解还是有点模糊。您这里也没有对应到拆分图上。
留言处不能贴图，我就手敲了一个响应时间拆分图如下：
| t1 | t2 | t3 | t4 | t5 | t6 |

---

| jmeter | | nginx | | tomcat | | mysql |

---

           | t12 | t11 | t10 | t9 | t8 | t7 |

我们理解如下：
ningx的请求时间 = t1
ningx的响应时间 = t7 + t8 + t9 + t10
tomcat的请求时间 = t1 + t2 + t3
tomcat的响应时间 = t7 + t8
作者回复: 看晕了。你加我微信画图吧。Zee_7D

2020-03-16

suke
老师看了你的专栏以及后面对tps的分析，最近在我们自己的项目上实践发现可行性上有一些问题，想请教一下：1、tps的瓶颈点（每线程tps最大值开始衰减的点）该怎么确定；2、拿到线程在并发递增情况下的tps趋势图 如何确定最大的tps，难道只是简单的取所有数据的最大值么？需不需要排除一些异常数据？3、我们在实际测试服务的性能过程中 每线程tps都是从开始就递减的，也就是说1割线程的时候tps最大，没有看到一个先上升在减少的过程？这种情况您遇到过么，还是我们实操的姿势不对？
作者回复: 联系我微信，发图给我看。Zee_7D

2020-03-11

大道
高老师分享的很用心
作者回复: 多谢支持。主要是我比较单纯，所以用心。哈哈。

2020-03-09

suke
老师，您说性能瓶颈在每线程tps的最大值，那jmeter有没有有什么插件可以直接算出每线程tps的时序图的？
作者回复: 没有的。只能自己算了。不过这个值在每个场景中都不会固定，所以不太可能在不执行场景的情况下直接算出来。

2020-03-09

suke
并发线程数线性递增的策略 例如您文章中提到的每次递增10个线程 如何在jmeter中实践呢？只是用ramp up来控制么
作者回复: 有插件。

2020-03-09

京都念慈菴
老师第一个问题我想讲我今天遇到的，换了个数据库，然后经常内存溢出或者服务器五百，处理一下可以用了，然后就要让我做一下压测，还在开发中项目，然后我做了单接口压测（就是简单的jmeter线程数：100,1000,5000,10000），然后到10000的时候tps就降到22左右，之前都是在50tps左右，然后我又加到6000发现tps开始下降。项目没有预定目标，也没有估计用户数，也没有其他信息，就是让我很快的压一下给结果。本人之前也没做过压测公司也没有人会做过或者会做，就是学习了jmeter基本使用和老师您的课，我这样来做给系统施压有没有问题，周末还有一个系统也需要做试压看情况，老师有没有建议，现在突然要做，真的很迷茫！现在我就知道压测一定要会分析，在这样一个情况下，如果只是施压，没有明确指标，压一下系统连怎么回复都不知道。老师我现在应该怎么恶补一下能对现状有所帮助。
作者回复: 看场景那一章。

2020-03-06

伊森
高老师，请问这个每秒活跃线程数怎么从jtl文件统计出来呢？另外我看到您有4幅图，其中一幅是线程数/秒，是不是就是我说的每秒活跃线程数？这个是如何通过jtl文件统计出来的呢？
作者回复: jmeter有生成命令呀。

2020-03-05

大石头
si 软中断不一定是“网卡队列”问题导致的哦
作者回复: 是的。软中断不一定是网卡队列。我这里的示例是因为网卡队列。

2020-02-09

童话
证据链查找是否有相关书籍推荐
作者回复: 整个专栏几乎都是在讲如何创建自己的分析树来确定具体的证据链的。
因为要的知识比较多，所以没有具体的某本书。要推荐只能是一堆书了。

2020-01-27

浅浅
老师，场景递增的经验值，那个表格不是很明白，麻烦老师再说说一下呀
作者回复: 就是响应时间短就递增慢点，因为tps高。

2020-01-21

王锦
老师，您好，有个问题想问下：
您给出的那个性能场景递增的经验值，为什么响应时间短，对应的递增幅度小，响应时间长对应的递增幅度大呢？
作者回复: 响应时间短，tps就肯定高呀。为了让tps增加幅度不太大，只有把线程数慢慢增加。

2020-01-15

二马
最后一个例子，增加jmeter后TPS增加了一倍，那么问题出现在哪里呢
作者回复: 说明在后面两个节点上，可以接着往后面加实例来判断。
这里我要说的是思路。

2020-01-10

小鱼
高老师，性能分析这块后面能不能细讲一点，多举几个实际项目中的例子，这块还是比较模糊的，感觉这块也是核心重点.比如下面的知识点可否抽一个单独的案例详细串联的讲一下呢？
从压力工具中，只需要知道 TPS、响应时间和错误率三条曲线，就可以明确判断瓶颈是否存在。再通过分段分层策略，结合监控平台、日志平台，或者其他的实时分析平台，知道架构中的哪个环节有问题，然后再根据更细化的架构图一一拆解下去。
作者回复: 正在写。
只是性能问题有很多，我尽量把思路说明白。

2020-01-06

小老鼠
如何预热数据，这章内容可作专门一个专题的，被填鸭了
2020-01-05

hinn
例子中场景用递增线程的方式施压，但是没有控制每秒服务器请求数（rps），请求线程完成一个循环直接发下个请求，压测的tps是当前线程服务器的最大处理量，此时硬件资源监控也只能看出当前处理量下的资源情况，各个阶梯的情况并不能很好的反映（rps和tps此时是不一致的变量多），我们用吞吐量控制器控制rps尽量让线程数和tps一致，这样更好分析定位。想听一听高老师对两种方法优缺点有没独到的见解。
作者回复: 首先，我不建议同时用RPS和TPS两个指标在同样的场景中来描述性能状态。你喜欢用RPS就单独用RPS，喜欢用TPS就单独用TPS。两个放在一起容易晕。
其次，控制不控制TPS，取决于场景的需要。如果控制到了100tps。服务器资源并没有用起来，还是要接着加压的。 如果你是想压到系统最大的容量，控制不控制，我觉得没有区别，因为系统最大的容量在既定的数据、软硬件环境等条件下也是固定的。 我们通常使用控制TPS的情况是在混合的场景中保持比例时使用。

2020-01-03

小老鼠
拐点指(错误请求数+失败请求数)/总请求数首次>5%处或响应时间首次超过规定值(比如3秒)的并发数值
作者回复: 这个说法不成立。没听说过有这样算的哦。

2020-01-02

robinlee
高老师，下面的线程指的是虚拟用户，还是操作系统查看的操作线程？

第一次计算，在线程达到 24 时，TPS 为 1810.6，也就是每线程每秒发出 75.44 个请求。
作者回复: 虚拟用户。

2020-01-02

Geek_9cc714
高老师，链路监控工具是不是都是需要嵌入代码里面，需要开发配合才能使用的
作者回复: 自己去配置下就知道，跟开发没关系。

2020-01-01

qhl
老师你好，在【性能衰减的过程】的示例图里面我看到，在线程达到 24 时，TPS 为 1810.6，平均响应时间是9ms。根据计算每个线程的TPS = 1000ms/9ms =111.11，111.11 * 24 个线程 = 2666，为啥显示的TPS是1810.6呢？
作者回复: 这个最基础的计算公式不可以在这样复杂的场景中应用。
它能说明的只是最简单的关系。
回头我再考虑下是不是应该再详细描述描述。

2019-12-30

土耳其小土豆
还有另一个问题，在性能测试中，线程数是否可以衡量系统性能？比如，领导就想看线程数倒多少的时候，系统回出现错误或者崩溃，在领导看来线程数就可以衡量系统的性能，有时候我也觉得挺合理。高老师觉得呢？
作者回复: 如果你能跟领导说清楚这个线程不是真实用户，并且领导也理解了。那就无所谓。主要是不能产生误解。

2019-12-30

土耳其小土豆
再问个问题，系统的TPS为什么总是和HPS一样的呢？前端发送的请求取决于服务器的处理能力？这样的话，不就不会出现连接超时的问题了吗？ 还请楼主有时间解惑一下
作者回复: 那说明你的T定义在了一个http 请求上。如果你的T包括了多个请求的话，你再看是不是一样的值。

不过不管你怎么定义，他们的趋势都会是一样的。

2019-12-30

简凡
1、为什么线程递增不能断？
不能断就是要要连续，连续就可以看到整体的变化过程，便于去分析，也是老师之前说到的趋势？
2、构建决策分析树
是要明白自己在做什么事，需要对哪些内容进行分析，分析的重点是什么，分析的路径是什么。

这篇文章需要多读几遍
作者回复: 理解的对。 可以动手了。

2019-12-30

奔跑的栗子
问题1：为什么线程递增过程不能断？
保持环境稳定干净，当性能指标出现变化时，可以排除线程突变原因
问题2构建分析决策树的关键是什么？
对架构/系统链路等足够了解，在分析问题时才能将问题逐个拆分定位；除了对架构/系统等有全面的认知外，多了解相关案例并分析熟记；
作者回复: 第一问：不是保证环境稳定干净。而是为了看递增过程中会不会出现系统的动荡。
第二问理解正确。

2019-12-27

漫漫
响应时间拆分太重要了，以前都是一个系统一个系统单独调接口测试，浪费时间而且也不准确，多谢老师提供思路
作者回复: 相互学习才能一直进步。
时间拆分在有些系统中简单，有些老系统日志打的差，又没有链路监控的。就费劲一点，不管怎么样，有思路总是有方法。

2019-12-27

nana
为什么线程递增过程不能断？构建分析决策树的关键是什么？
1.线程递增就是模仿线上流量逐步增加的过程，所以过程不能断
2.构建分析决策树的关键是分类，从相互独立的点去cover整个原因分析。
受益颇多，谢谢老师，期待更多干货。。。
作者回复: 第二点，主要是找到正确的路径。 不跳跃，就能找到瓶颈点。

2019-12-27

喜哥
后面图表分析 每秒请求是指每秒的请求数（RPS）吗 ，如果是，那么增加jmeter数量后，应该是每秒请求增加，而非tps增加
作者回复: 用tps，还是rps，hps…在我看来是一样的。只是叫法不同。这个在前面的篇幅中已经描述过了。

2019-12-27

王征
高楼老师这篇文章写的太棒了！
作者回复: 多谢肯定。

2019-12-27

Taylor
最后这个例子没太懂瓶颈的点，请老师指点
作者回复: 就是如果你不确定是非常完整的细节证据链。可以按整个机器或整个节点来做扩展的方式，来对比哪里是性能瓶颈。

2019-12-27