02丨性能综述：TPS和响应时间之间是什么关系？
0
1
思考题
如果你理解了今天的内容，不妨说说为什么说现在市场上的概念对性能项目的实施并没有太大的价值？其次，性能场景为什么要连续？而不是断开？
读者A：
第一个问题：
日常生活中价值可以通俗的理解为“合算不合算”，“值得不值得”，这里泛指对性能项目的有益程度。
在价值工程中，价值是个科学的概念，其定义为：V=F/C
式中：V——价值（Value）
F——功能评价值（Function Worthy）
C——总成本（Total Cost）
可见，包括三个基本要素，即价值、功能和成本。
功能可解释为用途、目的等等。对于一个性能项目来说，功能就是性能验证 or 性能分析 or 性能调优。
概念这里简单理解为“思维惯性”，其会决定做一个性能项目的行为模式，是指实现功能（性能验证 or 性能分析 or 性能调优）所支付费用（成本）。
SO，为了提升价值，在功能（目的）不变的情况下唯有适当的降低不合适的成本，那么这些杂七杂八，逻辑关系不符合真实的场景的概念势必需要淘汰。
第二个问题：
性能场景中的“场景”比较正宗的描述是：在既定的环境（包括动态扩展等策略）、既定的数据（包括场景执行中的数据变化）、既定的执行策略、既定的监控之下，执行性能脚本，同时观察系统各层级的性能状态参数变化，并实时判断分析场景是否符合预期。
那么如何看性能数据呢？
一般有两个核心即趋势和证据链。
分析数据趋势需要对一个时间序列数据的分析，一般采用线性回归分析。
对于证据链查找，需要对不同时间序列数据的分析，一般采用数据的相关性分析。
作者回复：你写的比我写的还要好。哈哈。下面的篇幅中就要有趋势和证据链的部分。这也是我觉得性能中最重要的部分。我混了混迹江湖十几年的依靠。
读者B：
性能场景为什么要连续？而不是断开？
递增线程数，记录每次的性能指标，对比分析，画曲线，来观察指标变化的趋势，找出性能瓶颈，或者服务器最大处理能力
作者回复：理解的非常正确。
作者回复: 理解的非常正确。
读者C：
请老师允许我一个新手留下自己的思考和疑问? 第一问，自己的思考是很多理论上的概念，不仅仅加深了我们对性能测试的理解的困难程度。同时，在实际发现性能瓶颈，实施性能优化，很多时候是没有太多帮助的。
第二问，之所以需要连续的一个符合实际的加压过程，是因为能够获取更加完整且准确的证据链。
个人疑问:关于如何去设计递增加压的过程，根据什么去设计，如何去设计出符合我们系统的加压过程?
对于老师的两问，个人理解不一定正确，希望老师指正。
对于个人疑问，麻烦老师留下思路。
最后，老师的讲的真实在，谢谢老师的分享。虽然有一些我还没办法懂，但是我会极力的去吸收。谢谢老师！
作者回复：
第一问：理解的很对。理论来自于实践，并且要再应用到实践中去。才是真正的有价值。
第二问：前半句说的对，就是要一个符合实际的加压过程。后面句方向有点偏，连续不是为了获取证据链，而是为了判断瓶颈点的出现和性能衰减的过程，分析这个过程产生的压力数据、监控数据得到瓶颈点的过程才是获取证据链的。
针对个人疑问：后面的场景中，会更详细的提到。在这里简单说一下，递增加压的过程是为了让一个系统的性能衰减过程可以清晰判断出来。而递增的量级就完全取决于业务系统的能力了。如果业务处理的响应时间长，在系统瓶颈还未明显出现时就递增的快一些；反之就慢一些。后续篇幅中再细看吧。
读者D：
1. 为什么说市场上的概念对性能项目实施没有太大价值?
看完第1、2讲,感觉老师真的是很真诚很负责,说出了很多我们想说不敢说的话
就拿老师举例的配置测试来说,我当时陆陆续续接触到这么些概念的时候就在想,这都谁造出来的词,连配置这么个基本操作也要上升到XX测试的程度...最搞笑的是还有一种叫“文档测试”的.感觉这些都太重理论轻实践了.
说个题外话,我以前虽然也对性能测试、压力测试、负载测试颇有微词,但自己也不能总结提炼出一个更好的分类框架或者体系, 今天看到老师用性能场景来作为划分依据,就是重实践的表现,很值得我们学习呢.
2. 为什么性能场景要连续不要断开?
说来惭愧,我第一个负责压测的时候就是用的离散的性能场景,也就是一次测试过程中线程数是固定的. 现实中的性能场景都不是一成不变的, 用固定的线程数去压测的意义很有限
作者回复:
能有这样的评论，我觉得很欣慰，有认同感。
我深受概念扰乱多年，总是得跟人解释一顿我认为对的概念和操作方式。
0
2
精彩问题
摘抄自留言区精彩的提问。
Q:
性能测试通过概念、模型、观测、实验等手段来进行问题的剖析。其涉及范围之广，从压力工具、操作系统、开发语言、数据库、消息队列、中间件、网络等各个方面。通常还需要深入的理解各种原理，特别是在一些重点细节上，往往需要有超出一般的认识和方法。
A:
深得真传呀。哈哈。
Q:
有全链路压测相关的实战吗？
A:
这个话题说大不大说小不小，在这个专栏中，我没打算讲全链路压测相关的话题。
不过既然这里问到，我大概描述一下我不打算写的原因。
全链路压测是两个部分。全链路 和 压测，压测部分要做的就是有清晰的标识，而全链路就是系统要做的链路改造。
从技术层面说，不管是使用同样的硬件做旁路应用，还是改造已有应用做链路标识识别，技术的实现手段都是成熟的。
我最近在设计一个全链路压测的模拟系统，开发很快就能做得出来。
但是全链路的难点在系统的庞杂和团队之间合作的推进。所以全链路是个管理协调的难度大于技术实现的事情，并不像很多人所说的那么高高在上。
Q:
后面会有全链路压测的讲解吗？
A:
没计划写全链路。这个话题可大可小。做个综述类型的感觉不落地，要是写细节，感觉一个新专栏都有了。
后续我考虑一下再决定如何写，即有落地又不至于写太多。
Q:
老师我想问一下理发店模型是什么模型？
A:
理发店模型只是排队论中的一个demo，单独拆出来理发店，不能称为模型。
像这样的demo我能举出一堆来：
1. 火车站售票窗口；2. 医院看病；3. 早餐鸡蛋灌饼摊；4. 地铁口；5. ......，所有可排队的地方都是这样的demo。
Q:
1、性能测试工程师就是全栈工程师喽，真正业内有多少可以达到？2、性能测试工作需要其他人参予吗？3、分布式系统与单机系统在性能上有无差别？若有差别，差別在哪儿？
A:
1，不一定是一个的需要全栈，一个团队能做到即可，甚至虚拟团队也可以，只要做好项目管理。
2，当然是需要的，主要看性能团队本身能做到什么程度。程度越深，和其他团队的沟通越顺畅。如果连推进性能问题定位分析的能力都没有，那就只能做性能验证了。
3，显然这两者有很大差别。分布式系统首先要做的就是响应时间消耗的监控拆分。定位到某节点后再定向分析。
Q:
感谢老师分享性能知识，从业务模型到实地开展工作，从基本功夫到工作价值体现，任何理论只有落地才能产生价值，才是有用得理论，不能拿书本中那些理论做对比，咱们从事工作分两方面产生价值，一方面提高效率，一方面提高质量。老师从这两方面下手，解决根本问题，让从事这方面得工作人员展示自己价值。
A:
深得真传了。哈哈。
Q:
因为所以的性能测试方法概念混淆，但是目标又很接近，边界也不明确，目标却基本一致，所以放弃概念，追逐目标，就是系统指标优化。
另外性能测试的核心调优需要链路式的分析，监控能够帮助印证这种思路。
A:
深得真传！
Q:
QPS=并发数*常数/RT , 也就是到瓶颈后加并发后RT增加QPS不变，那么瓶颈基本在RT增加的节点上
A:
你理解的很对。对性能来说，性能瓶颈肯定是在RT增加的节点的
Q:
有个问题想请教一下老师：
关于TPS与并发线程数，正常应该是以TPS作为系统容量的衡量标准，这个在系统性能比较好的时候很好和客户沟通（即TPS>并发数）。
但是在系统性能较低的项目中，有时候就很难和客户沟通，比如一次项目中，系统在2000并发，系统TPS就到了最大1500多，RT、资源利用率那些也还好；但是接着增加并发到5000时，TPS基本比较平稳，没有什么下降，响应时间才刚刚超时。
对于这种情况，在估算系统可支撑最大在线人数时，客户就觉得应该依据最大并发数5000去算（RT可接受时），而不是依据最大系统TPS1500多去算，他们觉得你的每1个并发都是模拟的1个用户在实际使用，而响应时间没超时，就说明可以支撑这个并发数的用户同时使用（假设并发度100%时）。
我从响应时间分析，感觉他们的说法也没毛病，但是理智告诉我，从TPS看系统每秒最大也就能处理1500多，其余的请求应该会在队列超时，或被拒绝，但是5000并发持续压测10分钟，也没看到大量超时或报错（千分之一以下），拿不出证据来支撑，感觉真是性能三观都要被颠覆，一直耿耿于怀，还请老师解惑！
A:
在你的描述中，响应时间也还好，是什么程度的还好？如果从2000到5000，TPS平移，那响应时间至少上升了2.5倍。
即使这时还没到响应时间超时，也只能说明超时时间比较长，请求都放在队列中去了。对终端用户来说，就是感觉上的系统卡死。
如果这时你再上线程，是不是超时就会增加了？
其实就是：压力机线程、TPS、RT之间的转换关系。
从系统用户的角度来看，系统性能是在不断下降的。而不是技术上来看，没有超时和报错就是性能还可以支撑。
Q:
老师划分的测试场景或者说类型很认同，几年前在银行做性能测试大家也是按这个来的，根据统计出的几种线上访问场景，比如正常日特殊日间峰值之类的真实tps(现在觉得应该用qps如果能获得的话)来作为目标tps，持续断开的分别以60%步长20%或按情况动态梯度加压持续20分钟的。后来到了互联网公司也业余测了一段性能，为了敏捷也能更好的看曲线，我也把测试搞成持续并连续的加压了，最后来得及的话再按最优tps单独稳定一段时间。因为最终测试手段往往综合了很多因素嘛，在互联网时为了快，就直接测出应用自身的容量情况和线上流量比一下即可。而在银行，测试目的明确就是想知道线上正常日的固定压力能不能支撑，所以固定断开执行，而加压也是测业务增长以后的固定值能撑不，毕竟有钱有时间有人力。我感觉从道理上最优的压力如果能持续稳定，可以说小于其的压力大小也都能稳定住了吧？
A:
根据测试的目标制定出合理的场景。你说的固定值能撑住，应该是稳定性场景的目的。
稳定性场景的要求其实挺高，要想真实模拟出线上稳定性的场景，不仅需要分析场景的有效性，还要考虑执行的成本等。
Q:
市场上性能测试是从测试目的和测试方法来描述性能测试概念，目的明确，能直观地给客户、上司等展示性能测试结果，满足需要。老师则是从我们性能测试人员实践出发，阐释了性能测试的本源，从而万变不离其宗，快准稳地发现问题，分析问题，解决问题。我觉得测试人员应该在掌握本源的基础上，站在用户、领导、运维等使用测试结果的人的角度解释测试结果，提出调优方案，方能沟通顺畅，更好地提现性能测试的价值。第二个问题，我更愿意用步进长度来说明，就像粗调微调一样，先粗调再微调，是不是会效率更高呢？
A:
专业方向是专业方向。从哪个角度这些概念都没有存在的价值。哈哈。
体现性能价值的地方，对于和非专业人士的沟通就是响应时间的提升、资源的减少。
第二个问题，不知道这个步进长度是啥意思。如果也是说的递增的话，那就无所谓了，含义一样，说法不同而已。粗调微调，都是根据实际的情况来的。后面会再提及。像用二分法之类的。手段是什么都可以，只要实现目标。
Q:
同时，递增的过程，也要是连续的，而不是 100 线程、200 线程、300 线程这样断开执行场景，这样是不合理的。
那请问是如何 慢慢递增起来的呢？是根据被压测系统的某种参数指标CPU、内存、响应时间。还是根据什么指标来增加线程数？
A:
根据响应时间的大小，后面篇幅中会写到这些。
Q:
在具体的项目实施中，有经验的性能测试人员，都会更关心服务端能处理的请求数即 TPS，而不是压力工具中的线程数。确实这句话。特别感同身受。还和不少人解释多次。太心累了
A:
看来是有吃苦的经验的。哈哈。