02丨性能综述：TPS和响应时间之间是什么关系？

精选留言(13)

• 

  @zzw

  第一个问题：
  
  日常生活中价值可以通俗的理解为“合算不合算”，“值得不值得”，这里泛指对性能项目的有益程度。
  
  在价值工程中，价值是个科学的概念，其定义为：V=F/C
  式中： V——价值（Value）
  F——功能评价值（Function Worthy）
  C——总成本（Total Cost）
  可见，包括三个基本要素，即价值、功能和成本。
  
  功能可解释为用途、目的等等。对于一个性能项目来说，功能就是性能验证 or 性能分析 or 性能调优。
  
  概念这里简单理解为“思维惯性”，其会决定做一个性能项目的行为模式，是指实现功能（性能验证 or 性能分析 or 性能调优）所支付费用（成本）。
  
  SO，为了提升价值，在功能（目的）不变的情况下唯有适当的降低不合适的成本，那么这些杂七杂八，逻辑关系不符合真实的场景的概念势必需要淘汰。
  
  
  第二个问题：
  性能场景中的“场景”比较正宗的描述是：在既定的环境（包括动态扩展等策略）、既定的数据（包括场景执行中的数据变化）、既定的执行策略、既定的监控之下，执行性能脚本，同时观察系统各层级的性能状态参数变化，并实时判断分析场景是否符合预期。
  
  那么如何看性能数据呢？
  
  一般有两个核心即趋势和证据链。
  
  分析数据趋势需要对一个时间序列数据的分析，一般采用线性回归分析。
  
  对于证据链查找，需要对不同时间序列数据的分析，一般采用数据的相关性分析。

  作者回复: 你写的比我写的还要好。哈哈。下面的篇幅中就要有趋势和证据链的部分。这也是我觉得性能中最重要的部分。我混了混迹江湖十几年的依靠。

  2019-12-17

  

   16
• 

  微冷花谢

  请老师允许我一个新手留下自己的思考和疑问? 第一问，自己的思考是很多理论上的概念，不仅仅加深了我们对性能测试的理解的困难程度。同时，在实际发现性能瓶颈，实施性能优化，很多时候是没有太多帮助的。
  第二问，之所以需要连续的一个符合实际的加压过程，是因为能够获取更加完整且准确的证据链。
  个人疑问:关于如何去设计递增加压的过程，根据什么去设计，如何去设计出符合我们系统的加压过程?
  对于老师的两问，个人理解不一定正确，希望老师指正。
  对于个人疑问，麻烦老师留下思路。
  最后，老师的讲的真实在，谢谢老师的分享。虽然有一些我还没办法懂，但是我会极力的去吸收。谢谢老师！

  作者回复: 第一问：理解的很对。理论来自于实践，并且要再应用到实践中去。 才是真正的有价值。
  第二问：前半句说的对，就是要一个符合实际的加压过程。后面句方向有点偏，连续不是为了获取证据链，而是为了判断瓶颈点的出现和性能衰减的过程，分析这个过程产生的压力数据、监控数据得到瓶颈点的过程才是获取证据链的。
  针对个人疑问：后面的场景中，会更详细的提到。 在这里简单说一下，递增加压的过程是为了让一个系统的性能衰减过程可以清晰判断出来。而递增的量级就完全取决于业务系统的能力了。如果业务处理的响应时间长，在系统瓶颈还未明显出现时就递增的快一些；反之就慢一些。后续篇幅中再细看吧。

  2019-12-18

   1

   2
• 

  LensAclrtn

  1. 为什么说市场上的概念对性能项目实施没有太大价值?
  看完第1、2讲,感觉老师真的是很真诚很负责,说出了很多我们想说不敢说的话
  就拿老师举例的配置测试来说,我当时陆陆续续接触到这么些概念的时候就在想,这都谁造出来的词,连配置这么个基本操作也要上升到XX测试的程度...最搞笑的是还有一种叫“文档测试”的.感觉这些都太重理论轻实践了.
  
  说个题外话,我以前虽然也对性能测试、压力测试、负载测试颇有微词,但自己也不能总结提炼出一个更好的分类框架或者体系, 今天看到老师用性能场景来作为划分依据,就是重实践的表现,很值得我们学习呢.
  
  2. 为什么性能场景要连续不要断开?
  说来惭愧,我第一个负责压测的时候就是用的离散的性能场景,也就是一次测试过程中线程数是固定的. 现实中的性能场景都不是一成不变的, 用固定的线程数去压测的意义很有限

  作者回复: 能有这样的评论，我觉得很欣慰，有认同感。
  我深受概念扰乱多年，总是得跟人解释一顿我认为对的概念和操作方式。

  2019-12-17

   1

   2
• 

  IT媚娘

  性能场景为什么要连续？而不是断开？
  递增线程数，记录每次的性能指标，对比分析，画曲线，来观察指标变化的趋势，找出性能瓶颈，或者服务器最大处理能力

  作者回复: 理解的非常正确。

  2019-12-17

  

   2
• 

  于欣磊

  QPS=并发数*常数/RT , 也就是到瓶颈后加并发后RT增加QPS不变，那么瓶颈基本在RT增加的节点上。

  作者回复: 你理解的很对。 对性能来说，性能瓶颈肯定是在RT增加的节点的。

  2019-12-16

   3

   2
• 

  Geek_alair俊

  完全赞同老师对性能概念的理解和区分，实际性能测试项目中，那些所谓的负载测试，压力测试，递增测试，配置测试等的概念，其实在实施场景的时候都有共同的点，那就是压力递增或者容量递增， 所谓的配置测试，无非也是在性能分析的过程中，对影响性能的配置因素分析的一个点，总归还是在容量性能测试或者负载性能测试涵盖的范畴，这不足以单独区分出一个个定义，更何况这么多定义有些还存在高度的重合或者模糊的难以区分。以上纯属个人理解，如有误区或不妥，还请指正！

  作者回复: 理解的非常正确。

  2019-12-21

  

  
• 

  小老鼠

  我认为一定要搞清性能测试分类，不知道分类且不乱方寸。

  2019-12-21

  

  
• 

  优洛.h

  
  老师划分的测试场景或者说类型很认同，几年前在银行做性能测试大家也是按这个来的，根据统计出的几种线上访问场景，比如正常日特殊日间峰值之类的真实tps(现在觉得应该用qps如果能获得的话)来作为目标tps，持续断开的分别以60%步长20%或按情况动态梯度加压持续20分钟的。后来到了互联网公司也业余测了一段性能，为了敏捷也能更好的看曲线，我也把测试搞成持续并连续的加压了，最后来得及的话再按最优tps单独稳定一段时间。因为最终测试手段往往综合了很多因素嘛，在互联网时为了快，就直接测出应用自身的容量情况和线上流量比一下即可。而在银行，测试目的明确就是想知道线上正常日的固定压力能不能支撑，所以固定断开执行，而加压也是测业务增长以后的固定值能撑不，毕竟有钱有时间有人力。我感觉从道理上最优的压力如果能持续稳定，可以说小于其的压力大小也都能稳定住了吧？

  作者回复: 根据测试的目标制定出合理的场景。你说的固定值能撑住，应该是稳定性场景的目的。
  稳定性场景的要求其实挺高，要想真实模拟出线上稳定性的场景，不仅需要分析场景的有效性，还要考虑执行的成本等。

  2019-12-21

   1

  
• 

  小老鼠

  1，我可能一直做的是电信领域的测试吧，我不知道为什么一定要连续，请指教。
  2，我们当时作并发测试是这样的，就是设置并发用户，然后不断地递增，看实际并反应用户数，若设置并发与实际并发用户不一致的时候，这时候就找到了并发测试的拐点。
  3，因为现在迭代非常的快，所以拐点住往非常重要，他是衡量下一个迭代和这个迭代作比较的当然可以弱，但是不能比以前的低95％以下。

  作者回复: 从描述看，我们在说的不在一个点上，有机会详细的沟通下理解上的误差。

  2019-12-20

  

  
• 

  许童童

  单交易容量测试是不是单个接口的压测？

  作者回复: 是的。

  2019-12-20

  

  
• 

  律飛

  市场上性能测试是从测试目的和测试方法来描述性能测试概念，目的明确，能直观地给客户、上司等展示性能测试结果，满足需要。老师则是从我们性能测试人员实践出发，阐释了性能测试的本源，从而万变不离其宗，快准稳地发现问题，分析问题，解决问题。我觉得测试人员应该在掌握本源的基础上，站在用户、领导、运维等使用测试结果的人的角度解释测试结果，提出调优方案，方能沟通顺畅，更好地提现性能测试的价值。第二个问题，我更愿意用步进长度来说明，就像粗调微调一样，先粗调再微调，是不是会效率更高呢？
  

  作者回复: 专业方向是专业方向。从哪个角度这些概念都没有存在的价值。哈哈。
  体现性能价值的地方，对于和非专业人士的沟通就是响应时间的提升、资源的减少。
  第二个问题，不知道这个步进长度是啥意思。如果也是说的递增的话，那就无所谓了，含义一样，说法不同而已。粗调微调，都是根据实际的情况来的。后面会再提及。像用二分法之类的。 手段是什么都可以，只要实现目标。

  2019-12-19

  

  
• 

  0273522

  同时，递增的过程，也要是连续的，而不是 100 线程、200 线程、300 线程这样断开执行场景，这样是不合理的。
  
  那请问是如何 慢慢递增起来的呢？是根据被压测系统的某种参数指标CPU、内存、响应时间。还是根据什么指标来增加线程数？
  

  作者回复: 根据响应时间的大小，后面篇幅中会写到这些。

  2019-12-18

  

  
• 

  Eight Baby

  在具体的项目实施中，有经验的性能测试人员，都会更关心服务端能处理的请求数即 TPS，而不是压力工具中的线程数。确实这句话。特别感同身受。还和不少人解释多次。太心累了

  作者回复: 看来是有吃苦的经验的。哈哈。

  2019-12-17

   1

  