LoadRunner集合点怎么设置，集合点导致并发不稳定又要怎么排查，做秒杀、批量提交、登录峰值、支付确认这类场景时经常会碰到。集合点的作用，是让一批虚拟用户在某个关键步骤前等着，等满足了释放条件再一起往下执行，它适合拿来制造某个业务动作的瞬时压力，不适合拿来替代正常的并发模型，要是设置得太随意，反而会出现用户卡住不动、释放的时候凑不齐、并发峰值忽高忽低这样的情况。

　　一、LoadRunner集合点怎么设置

　　集合点一般要放在真正需要并发去冲击的那个业务步骤前面，比如提交订单、确认支付、查询库存、批量保存这些地方，不要把它放在登录的前后随便去试，登录这件事本身会受到账号、验证码、会话初始化的影响，问题会变杂，集合点放的位置越是靠近目标的那个请求，测试出来的结果就越容易被解释清楚。

　　1、在脚本里面把集合点插进去

　　在VuGen里面，操作者可以在目标步骤的前头把rendezvous函数给插进去，比较常见的形式是lr_rendezvous，再给它加上一个清楚明白的集合点名字，比如submit_order、pay_confirm这样的，不要用那种临时起的中文名，或者是带着特殊符号的名字，集合点是要放在Action里面的关键请求前面的，不太建议把它放在初始化或者结束的动作里面，不然到了Controller里面就不太好去管理了。

　　2、在Controller里面把集合点启用起来

　　脚本被加到场景里面以后，操作者可以在【Scenario】→【Rendezvous】里面去查看集合点，然后把参与的用户、释放的策略还有等待的时间都给设置好。

　　这个地方是要留心一下的，脚本里面虽然写上了集合点，可不代表它在场景里面就一定会照着预想的那个样子去生效，要去看看集合点有没有被Controller给认出来，有没有被打开，参与进来的那个用户组它对不对，要是好几个脚本要在同一个业务点上被同时释放，那集合点的名字就要被保持成一样的，不然的话就会被当成不同的集合点去处理。

　　3、把释放的策略给设置好

　　释放的策略不要光盯着“全部人都到齐了再放”这一条，要是有用户执行起来慢、参数取值出了异常、前面的请求已经失败了，那其他的用户就会一直等着，到最后并发峰值反而不稳定，操作者可以照着场景的需要，把它设成达到一定人数就释放，或者是等够一定时间就释放，压测要的是能被控制住的并发，不是把所有的用户全给卡在一个点上头互相等着。

　　二、LoadRunner集合点导致并发不稳定怎么排查

　　集合点并发不稳定，先别急着去怀疑服务器的那个性能，很多的时候是虚拟用户根本就没有按照同一个节奏跑到集合点，有的被卡在了前面的请求上，有的参数拿失败了，有的脚本每次迭代跑出来的时间不一样，到了释放的时候自然就凑不齐了。

　　1、先去看看实际到了多少人

　　集合点被释放以前，先看看到底有多少用户跑到了，本来是计划一百个用户一块儿并发的去提交，可真正到了集合点的就只有七十个，那被放出来的峰值肯定是不够的，剩下那三十个没到的，就要接着去查，是登录失败了、关联没做成、参数被用光了，还是前面的那些事务响应太慢了。

　　2、检查前置步骤花掉的时间

　　集合点前面的步骤，要是它们花掉的时间彼此差得很多，用户到的时间就会被弄得散开了，比如说有的用户去查接口，一百毫秒就跑回来了，有的用户却被卡了五秒钟，那再集合的时候，等待的时间就被拉长了，这个时候可以把前面的步骤拆成一个个的事务，先去瞅一眼，在集合点以前，到底是哪一段它的波动是最大的。

　　3、检查参数和数据的唯一性

　　在并发的场景里面，要是账号、订单号、商品ID、手机号这些东西互相之间起了冲突，那用户就有可能在跑到集合点以前就已经失败了，从表面上看好像是集合点的并发不稳，实际上却是数据准备这一块没做够，特别是一次性的那些参数，要是迭代的次数和虚拟用户的数量没给算好，就很容易出现有一部分用户拿不到数据的情况。

　　三、集合点在使用的时候怎么让结果更可信

　　集合点这个东西不是弄得越多越好的，一个脚本里面要是塞了太多的集合点，用户的行为就会被弄得非常不真实，服务器压力的曲线也会被人为地给切成一段一段的，在实际的压测里面，最好是只在核心的那个动作上去设集合点，其他的步骤就照着业务自己的节奏让它自然地跑。

　　1、不要拿集合点去模拟全程的并发

　　真实的用户他是不会每一步都同时去点的，集合点适合拿来模拟某一个瞬间，比如整点去抢购、统一去提交、批量去审批这些个样子，要是连普通的浏览、查询、翻页这些全都给加上了集合点，结果看着倒是很整齐，可业务的真实性就会往下掉了。

　　2、配合着事务和监控再去看结果

　　集合点被释放了以后，要去瞧一瞧目标事务的响应时间、TPS、错误率，还有服务器的CPU、数据库的连接、队列的长度这些指标，光是瞅见并发的用户数上去了，这可不代表测试它就是有效的，最要紧的事情是目标的那个请求它到底有没有形成压力，系统它有没有跑出来瓶颈。

　　3、先拿小一点的规模去验证

　　在正式的压测被开始以前，可以先用上十个、二十个用户去验证一下，看集合点它能不能被正常地释放出来，等确认了脚本、参数、集合点的名字，还有Controller里面的策略全都没有毛病了以后，再动手去把用户的数量给放大，这个样子去弄，要比一上来就让几百号人一块儿跑，更容易把配置上面的问题给看出来。

　　总结

　　LoadRunner集合点怎么设置，集合点导致并发不稳定怎么排查，这里头的关键是先把集合点放在真的需要瞬时并发的那个请求前面，并且在Controller里面把参与的用户和释放的策略都弄好，并发不稳定的时候，先去看实际到了多少人，再去查前置步骤花掉的时间、参数的数据、脚本的错误，还有释放的策略，集合点它只不过就是一个拿来制造同步压力的工具，不是越多越好，用得准了以后，才能把关键的业务动作在高并发底下那个真实的样子给看出来。