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

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

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

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

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

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

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

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

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

作者回复: 好好学习，拍马屁也不能让你成长。哈哈

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