2019-12-27第一个问题：为什么线程递增过程不能断？
这里涉及开篇提到的性能分析能力 ——「趋势分析」。
就像之前提到的一样，分析性能数据趋势需要对一个时间序列数据的分析，一般采用「线性回归分析」算法。
回归分析研究的是多个变量之间的关系。它是一种预测性的建模技术，它研究的是因变量（目标）和自变量（预测器）之间的关系。这种技术通常用于预测分析，时间序列模型以及发现变量之间的因果关系。
假设有 N 个样本点，这里我们可以简单理解线性回归算法就是求一条直线 Y=f(X)，使得各点到这个曲线的距离的绝对值之和最小。
在这种技术中，因变量（TPS）是连续的，自变量（线程数）可以是连续的也可以是离散的，回归线的性质是线性的。
但在性能测试中，由于系统本身的最大 TPS 上限是固定的，即服务端的处理能力（容量）是固定的，如果自变量（线程数）压力过大，那么系统平均处理时间（响应时间）会被拉长。不过这个时候其实瓶颈早就出现了。
所以在场景压测中的自变量（线程数）递增一定需要是连续的，并且在递增的过程中要有梯度的，且场景中的线程递增一定要和因变量（TPS） 的递增有比例关系，且不是突然达到最上限，这样才能准确找出系统的瓶颈点。
第二个问题：构建分析决策树的关键是什么？
决策树基本上就是把我们以前的分析经验总结出来，在做决策树的时候，一般会经历两个阶段：构造和剪枝。
概念简单来说：
- 构造的过程就是选择什么属性作为节点的过程构造的过程就是选择什么属性作为节点的过程；
- 剪枝就是给决策树瘦身，这一步想实现的目标就是，不需要太多的判断，同样可以得到不错的结果。之所以这么做，是为了防止“过拟合”现象的发生。
从性能分析角度来理解：
- 构造：需要根据经验是对架构的梳理，是对系统的梳理，是对问题的梳理，是对查找证据链过程的梳理，是对分析思路的梳理；
- 剪枝：需要对对不同时间序列性能数据的相关性分析，其核心就是要理解各个性能指标的关系，同时进行证据链查找，根据数据的变化来推断得出各种结论，比如故障判别、根因分析等。展开 14
2019-12-27这节课我也期待了好久。高老师写的字数多点，总感觉不够看👀作者回复: 编辑小美女说我文章写太长了。😣😣
1 5
2019-12-27看到构建分析决策树就吓死了，数据库的知识，操作系统的知识都不懂啊，o(╥﹏╥)o作者回复: 慢慢来。反正不是吓死就是累死。
4- 2019-12-27第一个问题：不能断的原因是保证在测试过程中资源分配的合理性，减少偏差，便于分析出当前环境中的性能瓶颈点。否则断开后系统动态资源会重新分配，造成分析偏差。
第二个问题：构建分析决策树的关键好比如何画一棵树。先确定主干（主要流程），然后添枝干（组成部分），最后画树叶（定位问题）。从上到下，从左到右，拆分......
总的体会感觉给我这种测试野路子出身的工程师，又梳理了一遍如何定位问题的方法。让我对之前的工作实践中地操作有了进一步地理解。并且重新审视目前我所处的阶段：操作能力待加强。感谢老师，读完文章感到意犹未尽，希望在后续的课程能更加精彩。展开作者回复: 多谢肯定。
一看评论就是练家子出身的。多做总结，就会有更多的收获。 2 
2020-01-15果然是倾囊相授，谢谢老师xxe作者回复: 多谢支持。
1- 2020-01-06老师，再问一下，你文中发的递增经验值，后面的1-3指的是，比如第一个阶梯并发数是10，第二个阶梯并发数变为20-40，对么？另外，为什么响应时间越大后，并发幅度也变大呢？是因为响应时间变大后，并发幅度变化不大，可能看不出太大变化么？
作者回复: 响应时间越短，并发递增越小。
1 
2019-12-27做性能测试的我，对老师说的有着切身的感受，虽然此前也遇到老师所说的这些点，但从来没有像现在这样清晰，感谢~作者回复: 多谢肯定。我会再接再励。
1
2020-02-09si 软中断不一定是“网卡队列”问题导致的哦作者回复: 是的。软中断不一定是网卡队列。我这里的示例是因为网卡队列。
- 2020-02-09高老师，请问本节展示的四幅图：请求每秒、响应时间、线程数和请求/线程，都是jmeter自带的那个HTML报告生成的吗？如果是我没有找到请求每秒和请求/线程这两幅图，另外响应时间和线程数两幅图分别是对应的 Response Times Over Time和Active Threads Over Time吗？请帮忙确认一下在哪里找到这4幅图吗？谢谢
作者回复: 是我拿原始数据用excel生成的。
2020-01-27证据链查找是否有相关书籍推荐作者回复: 整个专栏几乎都是在讲如何创建自己的分析树来确定具体的证据链的。
因为要的知识比较多，所以没有具体的某本书。要推荐只能是一堆书了。
2020-01-21老师，场景递增的经验值，那个表格不是很明白，麻烦老师再说说一下呀😊作者回复: 就是响应时间短就递增慢点，因为tps高。
2020-01-15老师，您好，有个问题想问下：
您给出的那个性能场景递增的经验值，为什么响应时间短，对应的递增幅度小，响应时间长对应的递增幅度大呢？作者回复: 响应时间短，tps就肯定高呀。为了让tps增加幅度不太大，只有把线程数慢慢增加。
2020-01-11思考题
- 为什么线程递增过程不能断：因为中断的地方，可能会出现拐点。断了就看不到了
构建分析决策树的关键是什么：关键是对要分析系统的理解作者回复: 第一点：我不建议用拐点来描述，而是应该用抖动来描述会更好。哈哈。
第二点：非常对。- 2020-01-10最后一个例子，增加jmeter后TPS增加了一倍，那么问题出现在哪里呢
作者回复: 说明在后面两个节点上，可以接着往后面加实例来判断。
这里我要说的是思路。 
2020-01-09高老师，近期在验证tomcat 8 在NIO和APR两种模式下的性能差异。理论上APR在高并发的情况下性能更好一些，但是我验证的结果却是NIO的性能更好（同样的并发线程数，NIO模式的吞吐量更高，相同的吞吐量，系统的资源利用率相差并不大）。代码中只是设置了等待20或200ms然后打印输出字符，无任何逻辑。有些迷茫求高老师帮忙分析一下，多谢🙏作者回复: 虽然网上有很多写APR比NIO性能要好。但这个观点基本上是错的。
因为NIO、AIO、APR各适用于不同的应用场景。并且，也并不一定APR就一定比NIO、AIO性能高了。
所以你的结果应该是对的。不用迷茫。- 2020-01-06高老师，性能分析这块后面能不能细讲一点，多举几个实际项目中的例子，这块还是比较模糊的，感觉这块也是核心重点.比如下面的知识点可否抽一个单独的案例详细串联的讲一下呢？
从压力工具中，只需要知道 TPS、响应时间和错误率三条曲线，就可以明确判断瓶颈是否存在。再通过分段分层策略，结合监控平台、日志平台，或者其他的实时分析平台，知道架构中的哪个环节有问题，然后再根据更细化的架构图一一拆解下去。作者回复: 正在写。
只是性能问题有很多，我尽量把思路说明白。 - 2020-01-06老师，问3个问题，望能回复，先谢谢了。
问题1:文中提到“压力策略不会改变系统的最大TPS”，这个说法是不是有些绝对了呢？比如一开始就发起很大并发数让cpu，内存使用率都非常高，或者可能出现了数据库死锁等问题，我理解这种情况下系统的最大TPS比逐步递增压出来的最大TPS小，这个理解正确么？
问题2:“文中提到压测时要预热”，预热指的就是并发用户数从小到大逐步递增，对么？
问题3:“文中提到为了让性能瓶颈更显著，需要压到响应时间变长直到需要被拆分”的时候，这个具体是什么时候呢？因为并发数增加后，响应时间肯定会慢慢变长。作者回复: 1，一开始就加大压力的场景只会让系统忙于分配资源。这个场景就不合理。如果这样做，tps是有可能低的。
2，递增是一种预热的方式。还有其他手段，比如把数据先加载到redis里去等等。
3，这个没有特定的什么时候。只有根据场景具体判断了。 
2020-01-05如何预热数据，这章内容可作专门一个专题的，被填鸭了- 2020-01-03例子中场景用递增线程的方式施压，但是没有控制每秒服务器请求数（rps），请求线程完成一个循环直接发下个请求，压测的tps是当前线程服务器的最大处理量，此时硬件资源监控也只能看出当前处理量下的资源情况，各个阶梯的情况并不能很好的反映（rps和tps此时是不一致的变量多），我们用吞吐量控制器控制rps尽量让线程数和tps一致，这样更好分析定位。想听一听高老师对两种方法优缺点有没独到的见解。
作者回复: 首先，我不建议同时用RPS和TPS两个指标在同样的场景中来描述性能状态。你喜欢用RPS就单独用RPS，喜欢用TPS就单独用TPS。两个放在一起容易晕。
其次，控制不控制TPS，取决于场景的需要。如果控制到了100tps。服务器资源并没有用起来，还是要接着加压的。 如果你是想压到系统最大的容量，控制不控制，我觉得没有区别，因为系统最大的容量在既定的数据、软硬件环境等条件下也是固定的。 我们通常使用控制TPS的情况是在混合的场景中保持比例时使用。 - 2020-01-02拐点指(错误请求数+失败请求数)/总请求数首次>5%处或响应时间首次超过规定值(比如3秒)的并发数值
作者回复: 这个说法不成立。没听说过有这样算的哦。