2019-12-17第一个问题：
日常生活中价值可以通俗的理解为“合算不合算”，“值得不值得”，这里泛指对性能项目的有益程度。
在价值工程中，价值是个科学的概念，其定义为：V=F/C
式中： V——价值（Value）
F——功能评价值（Function Worthy）
C——总成本（Total Cost）
可见，包括三个基本要素，即价值、功能和成本。
功能可解释为用途、目的等等。对于一个性能项目来说，功能就是性能验证 or 性能分析 or 性能调优。
概念这里简单理解为“思维惯性”，其会决定做一个性能项目的行为模式，是指实现功能（性能验证 or 性能分析 or 性能调优）所支付费用（成本）。
SO，为了提升价值，在功能（目的）不变的情况下唯有适当的降低不合适的成本，那么这些杂七杂八，逻辑关系不符合真实的场景的概念势必需要淘汰。
第二个问题：
性能场景中的“场景”比较正宗的描述是：在既定的环境（包括动态扩展等策略）、既定的数据（包括场景执行中的数据变化）、既定的执行策略、既定的监控之下，执行性能脚本，同时观察系统各层级的性能状态参数变化，并实时判断分析场景是否符合预期。
那么如何看性能数据呢？
一般有两个核心即趋势和证据链。
分析数据趋势需要对一个时间序列数据的分析，一般采用线性回归分析。
对于证据链查找，需要对不同时间序列数据的分析，一般采用数据的相关性分析。展开作者回复: 你写的比我写的还要好。哈哈。下面的篇幅中就要有趋势和证据链的部分。这也是我觉得性能中最重要的部分。我混了混迹江湖十几年的依靠。
23
2019-12-18请老师允许我一个新手留下自己的思考和疑问? 第一问，自己的思考是很多理论上的概念，不仅仅加深了我们对性能测试的理解的困难程度。同时，在实际发现性能瓶颈，实施性能优化，很多时候是没有太多帮助的。
第二问，之所以需要连续的一个符合实际的加压过程，是因为能够获取更加完整且准确的证据链。
个人疑问:关于如何去设计递增加压的过程，根据什么去设计，如何去设计出符合我们系统的加压过程?
对于老师的两问，个人理解不一定正确，希望老师指正。
对于个人疑问，麻烦老师留下思路。
最后，老师的讲的真实在，谢谢老师的分享。虽然有一些我还没办法懂，但是我会极力的去吸收。谢谢老师！展开作者回复: 第一问：理解的很对。理论来自于实践，并且要再应用到实践中去。 才是真正的有价值。
第二问：前半句说的对，就是要一个符合实际的加压过程。后面句方向有点偏，连续不是为了获取证据链，而是为了判断瓶颈点的出现和性能衰减的过程，分析这个过程产生的压力数据、监控数据得到瓶颈点的过程才是获取证据链的。
针对个人疑问：后面的场景中，会更详细的提到。 在这里简单说一下，递增加压的过程是为了让一个系统的性能衰减过程可以清晰判断出来。而递增的量级就完全取决于业务系统的能力了。如果业务处理的响应时间长，在系统瓶颈还未明显出现时就递增的快一些；反之就慢一些。后续篇幅中再细看吧。 1 3
2019-12-17性能场景为什么要连续？而不是断开？
递增线程数，记录每次的性能指标，对比分析，画曲线，来观察指标变化的趋势，找出性能瓶颈，或者服务器最大处理能力作者回复: 理解的非常正确。
3
2019-12-16QPS=并发数*常数/RT , 也就是到瓶颈后加并发后RT增加QPS不变，那么瓶颈基本在RT增加的节点上。作者回复: 你理解的很对。 对性能来说，性能瓶颈肯定是在RT增加的节点的。
4 3
2019-12-30老师，我有个疑问。“单交易容量测试”是对单独接口进行压测是吧？比如针对每一个接口都测了100、200、300并发。那么这个测试结果和“混合容量性能场景”测完的结果应该怎么对比分析呢？作者回复: 不用对比分析。
做单交易容量测试是为了混合容量做基准数据的。举例来说。
业务1单交易容量能达到300TPS，且响应时间也非常好。而在混合中，可能业务1只需要100TPS，那就说明业务1不会成为混合容量的瓶颈点。
如果业务1单交易容量的时候只能达到50，而在混合场景中需要它能跑到100，怎么办？这就只能在单交易的时候做优化了。
所以单交易容量测试是为了确定是不是应该在单交易容量阶段做性能优化。
题外话：要注意的是混合容量中有相互的逻辑关系，这个必须到混合容量的时候才会出现。 1 2
2019-12-171. 为什么说市场上的概念对性能项目实施没有太大价值?
看完第1、2讲,感觉老师真的是很真诚很负责,说出了很多我们想说不敢说的话
就拿老师举例的配置测试来说,我当时陆陆续续接触到这么些概念的时候就在想,这都谁造出来的词,连配置这么个基本操作也要上升到XX测试的程度...最搞笑的是还有一种叫“文档测试”的.感觉这些都太重理论轻实践了.
说个题外话,我以前虽然也对性能测试、压力测试、负载测试颇有微词,但自己也不能总结提炼出一个更好的分类框架或者体系, 今天看到老师用性能场景来作为划分依据,就是重实践的表现,很值得我们学习呢.
2. 为什么性能场景要连续不要断开?
说来惭愧,我第一个负责压测的时候就是用的离散的性能场景,也就是一次测试过程中线程数是固定的. 现实中的性能场景都不是一成不变的, 用固定的线程数去压测的意义很有限展开作者回复: 能有这样的评论，我觉得很欣慰，有认同感。
我深受概念扰乱多年，总是得跟人解释一顿我认为对的概念和操作方式。 1 2- 2019-12-21完全赞同老师对性能概念的理解和区分，实际性能测试项目中，那些所谓的负载测试，压力测试，递增测试，配置测试等的概念，其实在实施场景的时候都有共同的点，那就是压力递增或者容量递增， 所谓的配置测试，无非也是在性能分析的过程中，对影响性能的配置因素分析的一个点，总归还是在容量性能测试或者负载性能测试涵盖的范畴，这不足以单独区分出一个个定义，更何况这么多定义有些还存在高度的重合或者模糊的难以区分。以上纯属个人理解，如有误区或不妥，还请指正！
作者回复: 理解的非常正确。
1 
2020-01-27老师，辛苦了，再请教个问题哈，基准性能场景，这个概念中，说将TPS压测到最大:这个怎么确定啥时候就是最大的呢？那TPS最大的时候要关注响应时间么？作者回复: 你有没有具体的TPS和响应时间图，拿一个出来，我给你具体说明。
2020-01-16老师，请问一下，线上的环境(各个用户单位提供的资源不一致)与测试的环境(公司提供的环境)存在差异，是按照比例进行指标的缩放，还是模拟各个用户的环境？哪一个更具说服力？作者回复: 没明白什么是“模拟各个用户的环境”。
按比例缩放是可行的。
2020-01-13想说作为一个没怎么接触过性能测试的后端开发人员，看起来有点吃力，比方说“当 CPU 资源使用率达到 100% 之后，随着压力的增加，队列慢慢变长，但是由于用户数增加的幅度会超过队列长度”这句话里的“队列"就不知道指的是什么，所以想问问老师如果之前没有接触过这方面的内容的话，可以补充哪些前置知识，有没有相应的书籍博客之类的推荐？Thanks♪(･ω･)ﾉ作者回复: 那要推荐的就多了。在知识图谱中，每个类型都要找一个书来看。并且要关注原理和性能方面的。
1
2020-01-131、理论在于实践吧，而实践才能出真知；书本上的理论可能是前人结合自己的不同场景，不同业务总结出来的，但是说起都适用就未必了，从业人员较少、真实实践的人不多，就导致了人云亦云。比如通常我也在做一些性能测试，老板不会关注过程，只会关注结果（换而言之就是想知道瓶颈以及有没有优化方向）；那么有些人会说一些2/8定律，网上拿来的公式，支撑几万并发（无任何条件），毫无根据的言论实在无奈。那么那些理论概念的测试大家真的都会做吗？
2、性能测试场景是为什么要连续？而不是断开？
其实自己在实践的过程中，场景通常是这样的：单交易基准、单交易负载····因为对基准的概念定义不一以及对性能测试认知模糊，就导致其实按照这个思路执行，并没有得不出什么有价值的结论；
一楼的大兄弟回答的很棒！
老师讲的也很好，尽快跟上脚步！展开作者回复: 跟上就知道这是完整的思路。不用考虑其他性能的概念。
2020-01-07思考题：说现在市场上的概念对性能项目的实施并没有太大的价值？其次，性能场景为什么要连续？而不是断开？
1. 首先定义市场上的概念是什么：我理解是说，单纯看TPS/QPS的标杆。说他没有太大价值，是因为它脱离了实际的使用场景
2. 性能场景要连续，因为实际用户使用的时候，压力的变化是连续的；而服务器如果有自动扩容机制，连续的压力变化也更符合服务器的扩容判断条件
问题：
- 曾经在一个项目中，因为 TPS 维持水平，并且用户数和响应时间一直都在增加，由于响应时间太快，一直没有超时。
是因为有Throttling么？展开作者回复: 前面理解的很正确。
问题回复：这种情况肯定是有瓶颈了。 1
2020-01-03再来温习一下
2020-01-011. 性能测试是一个挺大的概念，是需要进一步细化的，而且性能测试属于非功能测试的一部分，在很多项目中并没有得到很大的重视，往往是当线上发生问题时，在头痛医头，脚痛医脚。
性能测试的概念的厘清，有助于大家在一个频道上沟通，这非常重要。
2. 性能测试是一个持续的过程，有两个含义：1) 在一次性能测试的执行过程中，系统负载也是逐步递增的，关注单点的性能没有意义。2) 在系统性能调优的过程中，会多次执行性能测试，从而得出性能改善的程度。作者回复: 说的非常好。理念一致。
2019-12-30做了这么多年的性能测试，容量测试找拐点一致都是我头疼的，每次都是经过很多次反反复复的加压，梯度压测，最终找到拐点。经常会有无用功的时候，不知道高老师是不是也一样！有没有什么好的方法！谢谢作者回复: 哈哈，在我的理念中，就不用管拐点不拐点的事。
因为TPS在大部分场景中都是是缓慢上升的，是一个有明显弧度但没有明确拐点的曲线。
所以你要是问我方法，我会告诉你放弃这个拐点更为简单。
2019-12-23第一次用jmeter做压力测试，线程数从2到500个，TPS总是在600左右，响应时间增加了。服务器cpu使用率20%左右，是不是可以认为系统最大tps就是600呢？又该如何提高tps呢？带着这些问题订阅了老师的专栏，希望自己最后对性能测试有个整体的理解作者回复: 如果有详细的监控数据，分析到瓶颈并解决，很容易超过600。写专栏就是要对性能做整体的逻辑梳理。
1
2019-12-23有个问题想请教一下老师：
关于TPS与并发线程数，正常应该是以TPS作为系统容量的衡量标准，这个在系统性能比较好的时候很好和客户沟通（即TPS>并发数）。
但是在系统性能较低的项目中，有时候就很难和客户沟通，比如一次项目中，系统在2000并发，系统TPS就到了最大1500多，RT、资源利用率那些也还好；但是接着增加并发到5000时，TPS基本比较平稳，没有什么下降，响应时间才刚刚超时。
对于这种情况，在估算系统可支撑最大在线人数时，客户就觉得应该依据最大并发数5000去算（RT可接受时），而不是依据最大系统TPS1500多去算，他们觉得你的每1个并发都是模拟的1个用户在实际使用，而响应时间没超时，就说明可以支撑这个并发数的用户同时使用（假设并发度100%时）。
我从响应时间分析，感觉他们的说法也没毛病，但是理智告诉我，从TPS看系统每秒最大也就能处理1500多，其余的请求应该会在队列超时，或被拒绝，但是5000并发持续压测10分钟，也没看到大量超时或报错（千分之一以下），拿不出证据来支撑，感觉真是性能三观都要被颠覆，一直耿耿于怀，还请老师解惑！展开作者回复: 在你的描述中，响应时间也还好，是什么程度的还好？如果从2000到5000，TPS平移，那响应时间至少上升了2.5倍。
即使这时还没到响应时间超时，也只能说明超时时间比较长，请求都放在队列中去了。对终端用户来说，就是感觉上的系统卡死。
如果这时你再上线程，是不是超时就会增加了？
其实就是：压力机线程、TPS、RT之间的转换关系。
从系统用户的角度来看，系统性能是在不断下降的。而不是技术上来看，没有超时和报错就是性能还可以支撑。
2019-12-23我能理解为什么会有诸如配置测试这样的概念出现，这是从测试的目的或对象的角度更加细分了吧，虽然这些概念对测试实施没有太大帮助、测试人员所做的工作也没有太大的区别，但是它可以让非测试人员更好地理解测试工作。如果说得不对请老师指正。作者回复: 可以这样来理解它们的出发点。
只是不能称为性能测试的专业概念。- 2019-12-23关于TPS与并发线程数，有个疑问想请教一下老师：测试中，应该
2019-12-23看了你说的递增加压！那怎么判断初始应该上多少线程？然后在在这个基础上递增了作者回复: 你这个问题刚才在后续的篇幅之中，请稍候一两周。哈。
1