2020-01-16老师，您好。我是一名性能测试小白，想请教您一个问题。在做性能测试时，如何理解和定义业务？是实现这个业务逻辑的核心接口，还是完成这个业务操作所涉及到的所有接口？比如，我们目前打算上线一款APP，我想做一下接口的性能测试，评估服务器目前的承载能力，为后期服务器规划扩容提供数据支撑。由于目前没有实际的生产流量，因此我根据APP的特点，站在用户的角度分功能操作APP并用JMeter录制脚本，于是我设计了两个测试方案：
1.把每个功能看做一个业务，直接用录制的脚本做基准场景和容量场景的性能测试。
2.把每个功能看做一个业务，从录制的脚本中挑出完成这个功能的核心接口做基准场景和容量场景的性能测试。
对于我设计的方案，老师能说说您的看法吗？另外，能针对我的这个需求场景，给我一些实施的建议吗？展开作者回复: 你这1和2除了静态资源之外有什么区别？
如果静态资源线上是放在cdn上，那显然是选择2。
这个实施建议我不知道你说的是什么，这整个专栏中的都需要在实施中考虑的。像数据，业务比例，场景设计，监控设计等等。 2- 2020-01-15高老师，有哪些好用的工具可以辅助分析业务比例么？文中的比例图是怎么画出来的呀？
作者回复: elk就可以分析呀。比例图用excel就能画。
1 2 
2020-02-07这些图怎么来的 都不知道了作者回复: 生产环境中统计来的。excel都行。你有工具可用那就更好了。
2020-01-21高老师，请问业务数据是怎么统计出来的？作者回复: 生产日志统计来的。
2020-01-19Elk分析业务比例具体细节想了解一下作者回复: 这个直接统计就好了吧。ELK中有图可以生成，有时间段，有业务量的。
2020-01-171.为什么业务比例对性能场景如此重要？
不同的业务对系统资源的消耗完全不一样，如果业务比例跟实际的业务比例不一样，就会导致运行过程中资源消耗出现很大的偏差，那么得到的结果不够真实正确，也大大降低了性能测试的价值。
另外，如果生产流量来源是可以覆盖想要测试的业务场景的，可以通过生产流量扩大回放的方式实现压力部分，就不用考虑业务场景了。
2.如何在执行场景过程中控制 TPS 比例呢？
通常，在 LoadRunner 里，会用pacing来控制 TPS，而用 JMeter 的，则会用Constant Throughput Timer来控制 TPS。注意，JMeter中，Throughput Controller并不控制TPS。
另外请教老师，根据业务模型推算出各业务的TPS，从而根据公式，结合响应时间推算出压力机线程数。这个思路对吗？如果对，如何进一步确定压力机线程数配置，具体来说，问题1，响应时间怎么获取？是业务提出的，还是基准测试中获得的最大TPS对应的响应时间？问题2，推算出来的压力机线程数就是测试中的最大值吗？是否需要适当加大一些呢？如果需要，增加多少合适？如果不是测试中的最大值，怎么取值？问题3，在一次场景测试中，业务模型是一直要保持吗？比如说，起始线程数的配置也是要按业务比例计算吗？中间任一时刻都得按业务比例设计吗？展开作者回复: 思路是对的。
问题1：按基准测试中获取的最优响应时间来计算。
问题2：递增的比例要看具体场景了，和响应时间，tps量级，业务特点都会有关。增加比例就参考我写的经验值就行了。
问题3：业务模型是要一直保持的。所以不能只看线程数，而应该强调tps比例的一致性。- 2020-01-16老师讲的以tps来承载业务比例，和jmeter中按if控制器来配置不同业务的请求比例，很容易引起混淆。希望老师能澄清下这两个的区别。
作者回复: if控制器不能控制业务的请求比例呀。 我没有写if控制器哦。
- 2020-01-16刚好拿到了一个项目高峰期间的ng日志，正好可以按老师说的实践分析下啦。然后和项目上线前的预估比例和指标进行对比看看偏差。
作者回复: 做下看看结果。会感觉很有意思的。
- 2020-01-16问题一:首先只有混合容量性能测试场景下得出的tps才是最接近服务器能承载的最大或者说最佳容量，而混合容量场景却需要由事先确认好的业务比例来保证这个场景是有效的，最接近线上业务的。
问题二:我有个疑问，当我们使用Constant Throughput Timer时，肯定是需要事先设置好并发数的，我曾经试过在相同的请求数下，不同的线程数在刚开始跑的时候tps波动不一致，也就是说线程数越大，tps也越大，只不过随着时间推移慢慢接近设置的tps。而设置小的线程数整体的tps确实很平坦的。
还有就是老师这一次也没见您说递增式的场景？按我理解，无论是单交易还是混合容量，在压测时不应该都用递增式来逐渐达到最大tps吗？
请老师点评以及回答展开作者回复: 递增是所有场景的默认条件。我觉得前面已经强调的够重了。😃😃
2020-01-15每上线一个新系统就要求压压看，然后这时候是没有什么业务峰值的，就根据当前配置代码做个压测得出最大TPS，那么这里说到没根据生产业务模型是没意义的？还有必要做吗作者回复: 你这个也就是扫扫上了压力就出现的明显bug，其他没什么用。
1
2020-01-15高老师，看完文章有两个疑问：1 . 在jmeter中，业务比例是依靠什么承载的，是线程数吗？A业务占百分之八十，我就设置A为百分之八十的线程数吗？ 2. 那种按照一小时取平均tps 是不是太粗糙？ 比如 虽然一小时 是2000万的业务量，但是其中的1000万的业务量是在最高峰的10分钟产生的，高峰的tps其实是16000，作者回复: 根据tps承载比例。
2020-01-15Elk分析业务比例具体细节能介绍下吗作者回复: 暂时没有计划说这一块的内容。等后期全部更新完毕之后，如果有更多人询问这个问题。再考虑是否加餐。
2020-01-15答：
1、通过对生产数据统计能够完整体现系统业务的峰值数据，然后转换成具体场景中的业务模型，模拟真实的生产环境中的业务比例。不同的业务对系统资源的消耗完全不一样，如果业务模型跟线上的业务模型不一样，就会导致运行过程中业务比例出现很大的偏差，那么得到的结果不够真实正确，也大大降低了性能测试的价值。
2、执行场景中控制TPS比例的方法： LoadRunner 里，会用pacing来控制 TPS，而用 JMeter 的，则会用Constant Throughput Timer来控制 TPS。作者回复: 看来是理解了。
- 2020-01-15第一个问题我认为业务比例越趋近生产环境得到的性能数据越真实，生产流量的回放我理解的核心目的也是为了真实的覆盖所需要测试的性能场景，如果业务比例跟真实环境差距很大，那么得到的数据是没有意义的
第二个问题控制TPS比例需要根据线上的统计得到每个服务TPS的峰值及范围，不同的天数和时段TPS是不同的，需要根据线上的TPS的比例去测试系统的资源占用和性能指标，这样才能够真实的反应系统的性能情况，不论做系统当前性能测试还是未来系统的容量规划都是有意义的作者回复: 理解的很对。
1