极客时间已完结课程限时免费阅读

13丨性能测试场景：如何进行场景设计？

13丨性能测试场景：如何进行场景设计？-极客时间

13丨性能测试场景：如何进行场景设计？

2020-01-13 高楼 来自北京
《性能测试实战30讲》
课程介绍

讲述：高楼

时长24:41大小22.61M

我们在前面屡次强调了场景的重要性，今天终于到了要把实际场景拿出来解析的时候了。
在本篇文章中，为了保证数据的连续性，我用之前的项目资料来作明确地说明。同时为了模糊关键业务信息，以及让场景的描述更通用性，我会把所有的业务名隐去。
根据之前我们所说的，基准性能场景是为了测试出单业务的最大容量，以便在混合容量场景中判断哪个业务对整体容量最有影响。
今天的场景设计需要说明两个前提条件：
这些业务都是实时的业务，不涉及批处理、大数据等业务。
因为本篇着重讲场景的设计和具体项目的操作，所以不加系统资源的分析，避免信息混乱。
在这个场景设计中，首先，我们要列出自己要测试的业务比例、业务目标 TPS 和响应时间指标。
在这个项目中，响应时间指标是统一的，就是不大于 100ms。
其实我们在做项目的时候，经常会这样制定一个统一的响应时间指标，这样做也不是完全因为懒，更多的是根本不知道如何定每个业务的时间。但我们性能测试人员要知道，这显然是不对的，因为业务不同，响应时间指标也应该不同，合理的做法是给出每个业务的响应时间指标。下面我们还会遇到响应时间定得不够细致的问题。
有了这个列表，下一步就是做基准性能测试了。

基准性能场景

有很多人做接口测试的时候，觉得接口的 TPS 真是高呀，于是就按照最高的 TPS 跟老板汇报。但我们一定要知道的是，接口的 TPS 再高，都无法说明容量场景的情况，除非这个服务只有这一个接口，并且也只为了测试服务，这时就不必有混合的情况了。
首先，我们要知道，每个业务在系统中的最大容量是多少。那么接下来，我们用上面的业务一个一个地做基准，看看结果如何。

业务 1

场景执行时长：17 分钟。
先看 Statistics。
很多人喜欢用这个表中的数据来做报告，特别是 90th pct、95th pct、99th pct。我不是说不能用，但是，我们要先知道这个场景是什么样，再来确定这些值是不是可以用。
从上图来看，TPS 达到 573.24，平均响应时间是 109.83ms，发送字节很少，这里都没统计到，接收字节 966.22KB/sec，这个值也非常低，最小响应时间 43ms，最大响应时间 694ms。
但是！这能说明什么呢？什么都说明不了呀。是好是坏？不知道呀。所以我们还需要看其他图。
我们先看一下线程图。
以每分钟 15 个用户的速度往上递增。
对应的响应时间图是下面这样的。
随着用户的增加，响应时间一直都在增加，显然瓶颈已经出现了。
我们再结合 Statistics 表格中几个和时间有关的值来想想一想，90th pct、95th pct、99th pct、平均响应时间还可以用吗？ Statistics 的平均响应时间是 109.83ms，但是你从响应时间图和线程图比对就可以看到，在不同的线程阶梯，响应时间是有很大差别的。所以 Statistics 中的响应时间都是针对整个场景来说的，然而在梯度加压的过程中，用 Statistics 中的数据是不合理的。
接着我们再来看下 TPS 图：
我们可以从 TPS 图上看到，最大 TPS 能达到 680 左右。我再啰嗦一句，请你不要再用所谓的”最大 TPS 拐点“这样的描述来说明 TPS 曲线，我在第 6 篇文章中也说过，性能的衰减是逐步的（也有突然的情况，那是非常明显的性能瓶颈了），在最大 TPS 出现之前，就已经可以判断瓶颈是否出现了。
结合上面四个图，我们就有了如下的判断：
场景是递增的。
压力线程上升到 55（第四个阶梯）时，TPS 达到上限 680 左右，但是明显的，性能在第三个阶梯就已经接近上限了，
在压力线程达到 55 时，响应时间达到 85ms 左右，这个值并不高。
除此之外，其他的似乎不需要我们再做什么判断了。
也许这时候你会想问，那么瓶颈在哪里呢？总有人看到现象就想知道结果。但是这一次呢，我不打算满足这样的好奇心，因为本篇只是为了讲场景的逻辑，而不是瓶颈的分析。哈哈。

业务 2

从业务 2 开始，我们不做啰嗦的数据解释了，只说明一下关键点。我们看图。
Statistics 图：
线程数：
响应时间图：
TPS 图：
基于上面的四张图，我们可以看到：
这个单业务的最大 TPS 在 6000 以上。
响应时间变化比较小，基本上都在 10ms 以下，但也能明显看出在线程增加的过程中，响应时间也是在增加的。
这个业务由于 TPS 太高，响应时间太短，实在没啥可分析的。

业务 3

接下来再看一下业务 3 的情况。
Statistics：
线程数：
响应时间图：
TPS 图：
基于上面四张图，我们可以看到：
最大 TPS 将近 5000。
响应时间随着用户的增加而增加，在达到 4500TPS 时，响应时间在 6.5ms 左右。

业务 4

Statistics：
线程数：
响应时间图：
TPS 图：
基于上面四张图，我们可以看到：
最大 TPS 超过了 300。
响应时间随着用户的增而增加，在达到 300TPS 时，响应时间在 70ms 左右。

业务 5

Statistics：
线程数：
响应时间图：
TPS 图：
基于上面四张图，我们可以看到：
最大 TPS 在 550 左右。
响应时间随着用户的增而增加，在达到 550TPS 时，响应时间在 55ms 左右。

业务 6

Statistics：
线程数：
响应时间图：
TPS 图：
基于上面四张图，我们可以看到：
最大 TPS 超过了 2500。
响应时间随着用户的增加而增加，在达到 2500TPS 时，响应时间在 16ms 左右。
有了上面这些单业务的容量结果，我们就可以做一个表格了：
还记得我们前面提到响应时间都不能大于 100ms 吧。通过测试结果我们可以看到，业务 1 已经接近这个指标了，也就是说这个业务如果在活动或促销期，有可能出现峰值最大 TPS 超过承受值的情况，超过了前面制定的响应时间指标。
有了这些基础数据之后，下面我们就可以设计容量场景了。

容量性能场景

我们希望得到的容量场景在本文的一开始就已经给出。下面我们通过设计线程来得到这个容量场景的结果。
你需要记住我们的重点：
场景不断。
控制比例。
我们这里只说一个容量性能场景，并且这个场景是峰值业务场景。如果在你的项目中，有特定的业务日，那就要根据业务日的业务比例，重新做一个针对性的场景。
在满足了最开始提到的业务比例之后，我们不断增加压力，得到如下结果。
Statistics：
线程数：
响应时间图：
总 TPS 图：
TPS 细分图：
从上面的结果可以看到，业务 4 和业务 5 的响应时间，随着业务的增加而增加，这显然在容量上会影响整体的性能。
在具体的项目中，这就是我们要分析调优的后续方向。
还有一点请你注意，并不是说，看到了性能瓶颈就一定要解决，事实上，只要业务指标可控，不调优仍然可以上线。这一点也是很多做性能测试的人会纠结的地方，感觉看到这种有衰减趋势的，就一定要把它给调平了。其实这是没有必要的。我们做性能是为了让系统能支持业务，即使性能衰减已经出现，性能瓶颈也在了，只要线上业务没有超出容量场景的范围，那就仍然可以上线。
另外再说几句闲话，做技术的人容易钻进这样的牛角尖，觉得明显有问题，结果公司老板不支持去调优处理，显然是老板不重视性能测试，于是深感自己不得志，工作也无精打采的。这就没必要了，做性能不是为了炫技，应该为业务服务。
我们再说回来，从总 TPS 图上看到，在容量测试中，我们仍然测试到了系统的上限。这是一个好事情，让我们可以判断出线上的系统配置应该是什么样的。
在达到了系统上限时，我们来看一个业务的比例（请你注意，我是不赞同用表格来承载分析数据的，但是作为最终的结果，给老板看的时候，还是要尽量说得通俗易懂）。
如下所示：
我们可以从上面的数据中看到，业务目标 TPS 已经达到，响应时间也没有超过指标。很好，这个容量就完全满足业务需求了。
但是！
如果业务要扩展的话，有两个业务将会先受到影响，那就是业务 4 和业务 5，因为它们的测试 TPS 和最大 TPS 最为接近。这是在我们推算业务扩展之后，再做架构分析时要重点考虑的内容。如果是在实际的项目中，这里会标记一个业务扩展风险。
请你注意，根据架构，性能测试组需要根据当前的测试状态整理架构的关键配置给线上系统做为参考，并且每个项目都会不一样，所以并不是固定的内容。我想做运维的看到这些值可能会更为亲切。
在这里，我给一个之前项目中的示例（由于属于项目交付类文档，所以这里只截取部分技术片断），如下所示：
配置整理的范围包括架构中所有和性能相关的技术参数。如下所示：
当然，这时我们也是要分析系统的资源使用率的。在本文为了避免混乱，所以我没有提及。在实际的项目中，我们还是要分析的哦。
说完了混合容量场景之后，我们回忆一下之前说过的两个重点，我的混合业务场景是不是没有断？是不是保持了业务比例？
下面我们就该说一下稳定性场景了。

稳定性性能场景

我在第 1 篇文章就提到过，稳定性场景的时间长度取决于系统上线后的运维周期。
在这个示例中，业务 + 运维部门联合给出了一个指标，那就是系统要稳定运行一周，支持 2000 万业务量。运维团队每周做全面系统的健康检查。当然谁没事也不用去重启系统，只要检查系统是否还在健康运行即可。大部分时候运维是等着系统警告的。
那么针对前面给出的容量结果，容量 TPS 能达到 3800（业务 1 到业务 6 的容量测试结果 TPS 总和）。所以稳定性场景时间应该是：20000000/3800 = 1.46 小时。
下面是两小时的稳定性场景运行情况，我在这里只做一下大概的说明。
Statistics：
线程数：
响应时间图：
TPS 细分图：
总 TPS 图：
从上面几张图可以看出，业务 2 和业务 3 对总 TPS 的动荡产生了影响，但系统并没有报错。这种周期性的影响，你可以去分析具体的原因，由于本篇是场景篇，所以这里不写分析过程，直接给出原因，这种影响是参数化数据周期性使用所导致的，有些数据的关联记录数多，有些数据的关联记录数少，数据库中变化倒是不大，但由于 TPS 过高，表现出来得就比较明显了。
其他的业务都比较正常，也比较稳定，没有报错。
总体业务量达到 27299712，也达到了稳定性业务量级的要求。
有一点，估计会有人提出疑问，你这个稳定性的总体 TPS，看起来和容量测试场景中差不多呀，有必要用容量测试中的最大 TPS 来跑稳定性吗？
这里就涉及到另一个被误解的稳定性知识点了。有很多人在资料中看到，稳定性测试应该用最大 TPS 的 80% 来跑。看到没有，这似乎又是一个由 28 原则导致的惯性思维。
在这里我要澄清一下。在具体的项目实施过程中，完全没有必要遵守这些看似有道理，实则对具体项目没什么用的原则。
这个系统用最大 TPS 能跑下来，业务一直很正常，稳定性目标能达到，为什么不能用最大 TPS 来跑呢？本来稳定性场景就是为了知道会不会由于长时间处理业务而引发潜在瓶颈（像内存泄露是个典型问题）。至于用多大的 TPS 来运行，又有什么关系？只要系统在正常处理，资源没有出现问题，也没有报错，那这个场景就是有效的，目标也是能达到的。
所以说，这里的稳定性场景，完全合理。但是，你觉得这样就完了吗？当然没有，我们还有异常场景要做嘛。

异常性能场景

我之前有提到过，异常性能场景要看架构图，但是涉及到职业素养的问题，我这里只能画个示意图来说明此系统的架构，以此来实现逻辑的完整性。示意图如下所示：
这是一个完全按生产架构来的示意图，在真实的测试过程中，也是这样搭建的。在这里有六个业务区域（包含基础架构区），也有 DMZ 区。
其实在每个区域中，根据架构中用到的技术组件，异常测试都有细化的场景设计，而在这里，我给你展示一个全局架构层的场景，用来说明异常场景。
这里运行的场景是：用容量场景中最大 TPS 的 50% 来做异常的压力背景。
咦，是不是会有人问：这里为什么只用 50% 了？稳定性性能场景不是还用 100% 的压力背景嘛？
这里我就要再说一遍，看目标！异常性能场景的目标是为了判断所要执行的操作对系统产生的影响，如果 TPS 不稳定，怎么能看出来异常点？当然是稳定无抖动的 TPS 是最容易做出异常动作产生的影响了。所以这里的 50% 是为了得到更为平稳的 TPS 曲线，以便做出正确的判断。
下面我们就要看异常场景的设计了。这是一个大的异常场景。
我分别对各区域中的业务应用服务器、数据库服务器以及基础架构服务器做异常操作（为了方便理解，下文我直接用 kill 来说明，其实在操作中，有些不是直接 kill，像断电、断网卡的手段也都可以用，取决于如何操作更为准确）。
下面是具体的操作步骤和时间记录。
第一部分：业务应用服务器。停下如下区域的一半应用服务器，查看 TPS、响应时间及其他服务器压力。
kill 区域三：17:02；
kill 区域一：17:15；
kill 区域二：17:20；
kill 区域五：17:25。
第二部分：基础架构服务器。停下一半的基础架构主机，查看 TPS、响应时间及另外主机压力的恢复情况。
kill 一台基础架构主机中的某个服务的某个节点：17:30。
第三部分：数据库服务器。停下 master 数据库，查看切换时间，slave 的压力及 TPS 的恢复情况。
reboot DB-20：17:36。6 分钟之后恢复；
reboot DB-26：18:07。1 分钟左右恢复；
reboot DB-2：18:20。2 分钟之后恢复。
第四部分：启动 master 数据库。
第五部分：启动被停的应用服务。
start 区域五：18:28；
start 区域三：18:33；
start 区域一：18:38；
start 区域二：18:43。
第六部分：启动被停基础架构主机中的某个服务的某个节点。
start 基础架构主机中的某个服务的某个节点：18:48。
根据上面的步骤，这里我放出 TPS 图来做分析。
从上图中的 TPS 趋势可以看出，停掉一半的区域三应用服务器后，对 TPS 有明显的影响。为啥呢？
我们来看一下细分的 TPS 图：
从图上看，并不是所有的 TPS 都在步骤 1 的时候受到了影响。受影响的只有业务 2 和业务 3。显然只有业务 2 和业务 3 走到了这个区域。但是这仍然是一个 BUG！！！
理论上，用一半的压力，停了一半的服务器，即便当前正在运行在被停掉的服务器上的 session 受到了影响，那 TPS 也应该会恢复的，但是 TPS 没恢复。所以先这里提个 BUG。
另外，停掉区域一、二、五的一半应用服务器，影响不大，TPS 有些许下降，但并没有报错，这个结果还可以接受。
停掉基础架构服务器时，TPS 有下降，但很快恢复了，非常好。
在步骤 6 时，记录的信息是在 6 分钟之后恢复的，这个时间有点久了。我在这里拆开 TPS 细节来看一下。
显然这段报错得比较多，6 分钟，一个 master 库切换过去。这怎么能接受呢？报 BUG！！！
另外，步骤 8 中，TPS 显然下降到底了。还好时间并不长，在 2 分钟后恢复。这个可以报 BUG。为什么说是可以报呢？因为这个时间并不算长。这里就有一个预期的问题。通常情况下，我们做 DB master 的异常切换，在这个架构中，是期望在 1 分钟内完成切换的。在我这个场景中，最快的数据库 master 切换是 40s。
请你注意，我看到有些厂商说数据库可以达到秒级切换，这种说法未免过于空泛。如果把”不到 1 分钟“称为秒级的话，那就欲盖弥彰了。我理解的秒级切换是一秒内，而不是单位是秒就可以。
通常这种 1 秒内切换说的都只是数据库实例的前面一层，有叫 Plus 的，有叫 Proxy 的，并且说的不是从出现异常，到判断切换的过程。而是说从切换动作开始到结束。另外，这个秒级切换也是有背景条件的。我们不要看广告，要看实际的操作结果。
请注意，上面提到的容量场景和异常场景，都只是项目中的一个场景。其实在这个项目中，我还有很多其它的容量场景和异常场景。从场景设计上来说，这些场景都大同小异，但都需要在大量的调研分析之后才能设计得出来。

总结

在对基准场景、容量场景、稳定性场景和异常场景做了详细的，有逻辑的描述之后，相信你已经能体会到场景的博大精深了。
在本篇中，由于字数有限，我只对场景的具体执行过程中的关键点做了细致地描述。但是场景绝对不止这些哦，还有很多细节的内容。
同时，为了让理解更为清晰，这里我只描述了场景本身，场景包括的其他内容，比如说参数设计、监控设计等等，在本篇中都没有描述。
从这里，你大概能明白我说的场景对性能有多么重要了吧。
希望今天的这篇文章能给你在设计性能场景时提供参考。

思考题

看完了今天的文章，你能说一下性能场景应该按什么样的逻辑设计吗？以及在稳定性场景中，为什么不用最大 TPS 的 80% 来做？
欢迎你在评论区写下你的思考，也欢迎把这篇文章分享给你的朋友或者同事，一起交流一下。
分享给需要的人，Ta购买本课程，你将得18元
生成海报并分享

赞 7

提建议

© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
上一篇
12丨性能场景：做参数化之前，我们需要考虑什么？
下一篇
14丨性能测试场景：如何理解业务模型？
unpreview
 写留言

精选留言(98)

  • 杜艳
    2020-02-07
    还是不会做这些结果图啊，能对应jmeter讲解具体点吗？知道怎么分析了，不知道这些数据图怎么来的。

    作者回复: 这个专栏没有规划要讲jmeter的基本使用，所以不清楚你要讲的jmeter具体功能是什么，如果呼声高的话，后面，我可以加餐。

    共 15 条评论
    63
  • Coby
    2020-03-13
    高老师，您好。您的文章让我受益匪浅。这篇文章中有几个问题： 1.不同场景测试方法的问题。以前看到其他的性能书籍中介绍，基准性能场景是使用单线程做，目的是为了获取单线程时TPS值。容量性能场景是按照需测试的业务一个个做，找出最大TPS、线程数或瓶颈点；混合性能场景是按照业务比例（这个比例大多数是拍脑袋决定的）做；稳定性场景一般是按照时间长度，比如连续不断8小时、24小时、3x24小时等等。这样的做法不对吗？ 2.针对一个新开发的系统，没有上线使用过，不管是客户方的业务部门或者我方的产品经理均无法给出业务比例，这时这么确定业务比例呢？ 3.异常性能场景一般很少会被提及，渐渐大家都忘了这个场景。做这种场景的时候不用考虑单独一个区域中断的情况吗？比如您示意图中区域一、二、三、五都是应用服务器，只中断区域一中一半服务器后的TPS、响应时间情况。
    展开

    作者回复: 1. 不知道你看的是什么书籍，从我的理念上来说，那是绝对错误的理念。像你说的： “基准性能场景是使用单线程做，目的是为了获取单线程时TPS值。” 这个都不用测试呀，脚本直接跑一遍，看一下响应时间，就知道TPS了。这还能叫场景这么复杂的词吗？这就是验证一下脚本而已。 ”容量性能场景是按照需测试的业务一个个做，找出最大TPS、线程数或瓶颈点；混合性能场景是按照业务比例（这个比例大多数是拍脑袋决定的）做；“ 这个听起来似乎没有什么不同的逻辑。但是你说的”容量性能场景“和”混合性能场景“，从词的本身含义上来说，你能区分谁做什么吗？我觉得容量性能测试这个词就可以是混合的，按你这样的说法，我只能理解为”容量性能场景“其实就是单业务的最大TPS场景。如果这样的话“容量”这个词就完全不是它本来该有的含义了。而“混合性能场景”是在表达生产场景的含义，要非这么说也没什么，只是字不同。 只是在我的理念中：基准就是测试单业务的最大TPS；容量就是测试生产场景的所有业务混合的场景。这样清晰又简单，字面意思就能理解。 “稳定性场景一般是按照时间长度，比如连续不断8小时、24小时、3x24小时等等。” 在我看来，这样设置时间长度，必然不对。最简单的来说，你测试了24小时的场景，如果让你回答“系统什么时候会死”或者“系统能不能运行一个月”，可以回答得了吗？在我的经历中，我没看到有人敢拍着胸脯保证的。 不是因为时间长度不够，而是因为没有逻辑推算判断就直接拍了一个时间，自己也拿不准。 所以这样配置时间的思路必然是不对的。 2. 这个问题，我觉得好奇怪，很多人问。做为一个性能团队，业务比例也不是自己定的，为什么要把这个责任揽到自己头上呢？ 做为一个新开发的系统，如果连参照物都没有，那系统从哪来的呢？项目中没有一个人是有类似项目经验的吗？还是都不敢承担责任呢？就算是从线下搬到线上的系统也必然是有线下业务统计数据的呀。 在我的经验中，如果所有人都没有给的话。那我肯定会给出一个最傻瓜的比例，那就是所有业务都是1：1。这时你拿着1：1的业务比例跟别人讨论时，别人就会有意见了：“你这个1：1配置不合理呀？！” 好吧，那不合理的话，你为什么不给一个？这时肯定会有人说，这个业务应该是比一点，那个应该少一点。你看，这时候是不是业务比例就开始慢慢要形成了。 不过还是奉劝做性能的人，不要背这个锅。 3. 异常场景肯定是从小做到大的。每个区域中的每个组件，甚至到参数，我们都要做的。只是在一个文章中没法尽述，我只能举一个最复杂的最大的例子。如果全写出来，我估计还得来30多篇。

    共 2 条评论
    31
  • kubxy
    2020-03-14
    在容量场景中，您说要控制比例。这里控制的是什么的比例？线程数吗？您这里没有给出Jmeter的配置（具体环境的上下文缺失），很容易导致理解上的误区。

    作者回复: 工具操作类的，觉得在度娘上能找到，所以没有写。不然有些有经验的就认为专栏过于基础了。 你的这个可以在jmeter中用throughput controller实现。直接输入比例值就可以。如果具体不会操作，可以在微信上找我。

    共 7 条评论
    9
  • Geek_f93234
    2020-02-09
    老师，文中的这段话：在这个示例中，业务 + 运维部门联合给出了一个指标，那就是系统要稳定运行一周，支持 2000 万业务量。运维团队每周做全面系统的健康检查。当然谁没事也不用去重启系统，只要检查系统是否还在健康运行即可。大部分时候运维是等着系统警告的。那么针对前面给出的容量结果，容量 TPS 能达到 3800（业务 1 到业务 6 的容量测试结果 TPS 总和）。所以稳定性场景时间应该是：20000000/3800 = 1.46 小时。 不明白稳定性场景时间为什么要这么计算？能详细分析一下吗？ 还有我之前看到的很多都是这么来确定稳定性场景的执行时间的：一般来说，对于正常工作日（8小时）运行的系统，至少应该能保证系统稳定运行8小时以上，对于7*24运行的系统，至少应该能够保证系统稳定运行24小时以上。
    展开

    作者回复: 一个系统只有一种情况会需要像你这样来设计场景，就是系统的稳定性只和时间和关，和业务积累量无关。 我说的是用计算业务积累量的角度。

    共 4 条评论
    8
  • Geek_65c0a2
    2020-01-13
    高老师，我有个小白问题哈。为什么容量测试的结果会比单业务测的结果高呢？😄

    作者回复: 走的路径不一样。单业务涉及到的机器也没有容量场景涉及的机器多。

    7
  • 😂
    2021-03-26
    老师，您好，目前最大的疑问就是我应该设置多少个线程去压测，递增策略和递交策略，持续时间，这些该如何确定啊？

    作者回复: 这个之所以没有固定的说法是因为它本身就没法固定。 要根据实际的业务场景去做相应的调整才可以。 通常我的做法就是： 1. 先确定单线程时响应时间是多少。假设响应时间在10毫秒以下，我会一个一个线程增加，因为tps在这时增加的很快。这就确定了梯度。 2. 我会用二分法确定系统的上限。比如说，我先加100个压力线程，看系统的tps是多少，如果这时tps没到上限，就用200个压力线程，以此类推。但如果在100个压力线程时就已经达到了tps上限，我会降到50压力线程再看，直到得到合适的压力线程为止。这就确定了压力工具中的线程数。 3. 持续时间在容量场景中，对我来说，我只要看到稳定运行一段时间即可，通常我会用一小时左右的持续时间。

    共 3 条评论
    6
  • kubxy
    2020-03-14
    老师，性能场景中，比例控制这一块您能否结合jmeter等性能工具的具体设置来讲解？这里直接上测报报告，让我们这些性能测试新手理解起来很困难。总有一种是懂非懂的感觉

    作者回复: 另一评论中已回复。

    5
  • rainbowzhouj
    2020-01-14
    高老师，您好。以下是我对两个思考题的回答。 第一个问题： 性能场景设计前应了解实际场景中对应业务的目标值。然后查看对应业务的组成，采用先局部后整体的思想进行性能场景设计。具体而言，就如文章中所述先将单业务的基准性能测试结果得出，再进行混合业务的性能测试。值得一提的是通常情况下时间是稀缺资源，所以进行性能场景设计时，应时刻谨记以终为始的理念，得出结果后判断是否能满足业务目标。 第二个问题： 二八法则好比万金油，换句话说就是可有可无，进行稳定性场景的测试就是为了知道会不会由于长时间处理业务而引发潜在瓶颈。此时已经了解了对应业务的目标值，那么只要系统在正常处理，资源没有出现问题，也没有报错下，业务目标能满足，而且更确信，这样会更好。
    展开

    作者回复: 理解的挺正确。

    4
  • 村夫
    2020-01-13
    老师，有几个问题和想法。首先场景不断这个应该怎么理解？其次是老师例子中的业务一到六是一个接口还是多个接口？再次是控制业务比例，如果可以拿jmeter举例子会好很多，让我们能把您的想法落地，前面那几篇工具篇能匀一篇说业务比例如何设计该多好。最后是容量场景下最大tps应该怎么看？我看您的图都是曲线图，难道是看曲线图约摸着得出一个结果？

    作者回复: 场景不断，就是从低到高线程递增。 业务1到6，都是有业务含义的，后端会有很多个接口。 控制业务比例的过程通常是这样的：1. 先是拿线程数和TPS、响应时间来计算业务比例来做；2. 当运行过程中出来业务比例偏差时，就调整线程数；3. 在jmeter中可以有控制吞吐量的控制器。 业务比例设计的后面有一篇是专门描述这个的。 最大TPS，我是通过曲线图的一段来做计算的，你要是“约摸”这个词，也不是不可以。哈哈。

    4
  • 学员141
    2021-09-13
    老师，批处理、大数据这种业务是不是不用脚本，直接准备批量数据，实时调用分析？

    作者回复: 对呀。

    3
  • 月亮和六便士
    2020-04-04
    高老师，请教一下，容量测试的时候 ：假如有三个接口，没有顺序，但是有业务比例，是不是把三个接口放一个线程组里，每个接口添加事物，按照业务比例设置throughput controller控制就可以，如果有顺序，设置一个大事物就可以？

    作者回复: 是的，我理解你说的这样设置没问题。

    3
  • Geek4%
    2020-02-27
    老师，需要怎么设置线程与时间关系才能出现阶梯的TPS图

    作者回复: 设置ramp-up就可以了呀。

    共 3 条评论
    3
  • johnny
    2021-05-18
    老师，关于文中的混合业务线程数图。 我有两个问题，帮忙解答一下。 问题1：各业务的线程之间的比例和业务比例是不是比较接近？ 问题2：各业务的线程递增策略是不是不一样（基准场景中响应时间快的业务会设置的线程递增较慢些，相应慢的业务会设置线程递增较快些）？

    作者回复: 1. 根据响应时间计算出来看了才知道。 2. 搞不懂这个思路从哪来的。难道是要两个业务相互追平的意思吗？在我的逻辑中递增策略相同即可，关键是保持住业务比例。

    2
  • SeaYang
    2021-04-02
    高老师，之前面试时面试官问秒杀活动怎么设计压测场景，我说梯度加压得到最大稳定Tps，再结合限流策略保障稳定性。但面试官不认可，说秒杀是突增流量，不是梯度流量。我再说可以考虑集合点的方式模拟突增流量，面试官才说是他想要的点。。。可我还是觉得不管是不是秒杀活动，系统最大稳定tps都是会有一个确定的值，只是对于秒杀来说，需要采取限流、降级等策略来保障系统不挂。对此，老师您怎么看呢？

    作者回复: 你可以做一个示例来看一下。 递增在秒杀场景中也是可以适用的，只是递增的速度很快。集合点其实只是压力工具中的集合，并不是服务器端的集合。 如果考虑服务端对同一请求的同时的处理，注意哦，那是在不同的线程里。

    2
  • jy
    2020-06-01
    1、稳定性场景，是不是只要跑运维周期的业务量即可？而不是运维周期这个时间长度？ 2、运维周期是个什么概念？我们没这个说法呢

    作者回复: 1. 只要跑运维周期的业务量即可。 2. 就是多长时间做系统的清理、巡检等。

    2
  • jy
    2020-05-31
    我们平时在很多场合下所说的场景范围都有些狭隘，觉得场景就是业务比例，就是用多少数据。而实际做过多个性能项目之后，你就会发现，工具中的一个小小的配置，也会对结果产生巨大的影响。【------摘抄自第四课】 场景如何转换为压测脚本？文中只有非gui的html报告截图，完全看不到jmeter脚本一个大概的设计，比如，是单线程组还是多线程组？业务比例通过什么来控制？线程设置多少或者如何算？ 我觉得这是关键的一环，但是缺失了。希望老师能补充
    展开

    作者回复: 我在写的时候考虑到这个是工具的功能，所以没有写细。这个是单线程组、多线程组都不重要，业务比例控制方式也有好几种，所以没有一一列举。

    共 2 条评论
    2
  • 小呀么小二郎
    2020-03-24
    今日思考题： 性能场景应该按什么样的逻辑设计？ 按照基准性能场景、容量性能场景、稳定性性能场景和异常性能场景来进行设计。 在做基准性能场景前，需要先列出自己要测试的业务比例、业务目标TPS和响应时间指标。业务比例通常是由生产环境统计的数据得出的。 基准性能场景的目的是为了测试出单业务的最大容量，以便在混合容量场景中判断哪个业务对整体容量最有影响。 容量性能场景的目的是为了模拟真实生产环境的业务进行测试，保证性能测试的有效性。测试重点是场景不断以及控制比例。容量性能场景不止一个。 稳定性性能场景的目的是为了知道系统是否会由于长时间处理业务而引发瓶颈。时间长度取决于系统上线后的运维周期。 异常性能场景的目的是为了判断所执行的操作（比如kill、断电、断网卡等）对系统产生的影响，测试过程中要保持TPS的稳定（通常用容量场景中最大TPS的50%来进行测试）。异常性能场景也不止一个。 性能场景应该按什么样的逻辑设计？ 首先，稳定性性能场景的目的就是为了知道系统是否会由于长时间处理业务而引发潜在瓶颈，对于用多少TPS没有具体的要求。 其次，如果系统用最大TPS跑下来，业务一直正常，那就达到了稳定性性能目标，这个场景是有效的。既然有效，那么用最大TPS是没有问题的。 最后，理论要结合实际，我们在测试的时候也要结合场景目标以及系统真实情况来做，而不是道听途说的“原则”。 老师这节课的干货太多了。我需要找个实际项目练练手才能消化了。
    展开

    作者回复: 很快就出师了！

    2
  • 顺利
    2020-01-17
    拿到基准测试的结果后，您是如何按照业务比例设计出容量性能场景的，这块弄不懂，文中也没有计算的过程，不知道基准测试结果起到说明作用，老师能否详细说明。

    作者回复: 业务比例在容量场景中直接通过控制tps来体现就可以了。后面说了工具中各用什么功能来控制。不知道你的具体疑惑点是什么呢？ 基准测试起到的作用就是先把最基本的瓶颈解决掉。我这里已经给出的是优化后的基准测试结果。其实这个过程中遇到的瓶颈很多。 只有先把这些问题解决，基准测试的响应时间和tps才能对容量测试有比对的作用。

    2
  • kubxy
    2020-01-13
    老师，我一直有一个疑问。在做业务的性能测试时，是只测实现这个业务逻辑的接口，还是要测完成这个业务时访问的所有接口？比如，登录业务。在接口文档里只是一个登录接口，但使用JMeter录制登录操作，还会请求其他接口。

    作者回复: 你这个问题的前提是：你想做的是什么场景？ 只有分析了你要做的场景，才能判断出应该如何访问接口。 比如说，你的目的是只测试登录，那就完全没必要请求后面的接口。即使是录制实现了登录，并且连带了后面的接口请求。也应该把后面的接口请求给删掉。

    2
  • 土耳其小土豆
    2020-01-13
    先占个坑
    2