性能测试中的集合点
作者：互联网
集合点：同一时刻去发起请求，主要应用场景是秒杀
Q：不设置集合点的测试，能代表是“并发”操作吗？A：有这样一种说法，设置集合点是为了确保“严格意义上”的并发，其实从本质上看，这主要是一个看问题的粒度大小的问题。集合点的作用是通过工具的控制，确保一个请求严格地“同时”从前台提交到后台。可是如果微观地看，是不存在严格意义上的并发的，即使在客户端通过设置集合点的方式将100个请求同时提交到后台，经过网络上的传输消耗，可能它们并不是同时到达的，而即便100个请求同时到达服务器端，受到中间件和应用系统、数据库的各种连接池、缓冲区，CPU处理队列等的限制，也可能在服务器端产生等待的。因此，严格意义上的“并发”可以说是不存在的，我们需要做的是在可以接受的粒度范围内取得一个最佳的平衡点，站在这个平衡点的层面上去看待“并发”这个问题。
性能测试无非有两个目的，一是评测，二是调优。
在以评测为目的的性能测试中，用户更关心的是业务上的并发，也就是真实业务场景的并发情况，这种情况下只要按照业务操作的模式去设置场景就可以了，并不需要设置集合点。
集合点是一种特殊情况下的并发，通常是在以调优为目的的性能测试中才会用得到，目的是有针对性地对某个可能存在性能问题的模块施压，以便找到性能瓶颈。
集合点在我实际的测试过程中用得并不多。 实际业务情况对同一时间点并发要求很高（强事务要求的场景），可以设置集合点 需要模拟多个用户恰好在同一时刻执行任务，这时候就需要创建集合点 什么是集合点 集合点可以简单得理解为一种控制虚拟用户行为的机制，该机制可以达到在一定时间范围内将一定数量的虚拟用户阻挡在一个操作行为点前的位置进行互相等待，在条件（达到虚拟用户数量或超时）到达后唤醒全部等待中的虚拟用户，从而达到使得一定数量的虚拟用户可以同时进入下一个操作行为点的目的。 往往其使用初衷是为了实现最大意义上的并发来考察系统应对此种极端情况的表现。 达到增压的目的了吗？ 集合点真的可以达到对系统增加压力的效果吗？ 事实是不一定的（这种情况一般出现在ThinkTime和KeyTime被置0的前提下），这和你对其的使用方法和系统本身的构造息息相关，遇到的真实情况可能是在某个操作行为点上加了集合点后，整个事务性能变得更好了，这听起来有点不可思议，但你可以尝试分析一下原因： （1）当用户同时起步向前的时候，系统可以更加轻松的应对 混乱场面下的用户可能会各自处在不同的业务操作点下，有些在查询，有些在插入，有些在更新，这会对数据库的事务完整性控制提出要求，数据库会通过读提交、可重读或同步序列的方式，利用表级锁、行级锁来避免脏读和幻读的出现从而避免破坏ACID，在这种情况下必定会产生大量的锁竞争，对性能会产生一定损耗。 但在用户同步调的进行业务操作时，往往会大幅度的降低这种锁竞争的局面，另外，这种情况下更加适合于缓存这种利器效果的发挥，这对系统来说会省下了不少力气。 （2）集合点的出现会明显缓解服务端所直接承受的压力 单独业务点上虽然看似集合后压力增大了，但是这个要分析具体情况，首先，在释放阻塞之前，用户会处于互相等待的状态中，往往会有一些表现不尽如人意的用户拖了后腿，于是工具会陷入漫长的阻塞状态中，对服务端的压力逐渐减小，服务端的压力得到明显缓解，从而得到了喘息和休整的机会。 （3）测试工具统计结果中会加入等待时所产生的数据 用户都在集合点互相等待会导致TPS直线下降，原因是测试工具一般会把这段时间所产生的数据也算到统计中，这就会造成在最终使用这份工具生成测试结果时的一些困扰，需要利用原始值进一步加工。 正确使用集合点 首先，不是特别建议你在测试场景的设计中加入集合点，实际上在忽略ThinkTime和KeyTime的情况下，已经可以叫并发测试了，而且效果也完全达到了预期。 如果想使用集合点，你要有十分充足的需求作为导向。另外，建议将大事务拆解为更加短小精悍的几个小事务，并且通过分组运行调节这些事务之间的关系，比如一个组可以跑整个大事务或一些组按事务混合比跑其中几个小事务串儿作为持续不断的压力背景，在这种情况下精选几个关键性业务下的事务组合放入集合点，一个一个的在压力背景环境下下运行测试，重点关注它们的真正并发表现。 一些其他用途 （1）处理业务流或数据流上下游关系 当业务流或数据流继承关系要求耦合性非常高时，比如下游所需要处理的业务或数据必须依赖于上游所有或一定量用户完成相应业务处理或产生数据的基础上，可以利用集合点达到正确处理这类关系的效果。 （2）流控 当配合一些逻辑判断脚本或工具组件时，通过判断是否在一些特殊条件满足的情况下启动集合点，可以达到用户流量控制的效果。
标签：事务,性能,用户,业务,并发,集合点,测试 来源： https://www.cnblogs.com/seamy/p/15648419.html