http://wenku.baidu.com/link?url=2wZd7nx0zyPtDOsOEyVFnw4sEiKLvyHLnkNDz9HlOlRzZWEkCDhODdmNGebFrv5oVKj9rpS7Flg5qhXov-wbHghRtQWdIqKcX-0oRe7_7sG

1.集合点的含义 rendezvous

当通过controller虚拟多个用户执行该脚本时。用户的启动或运行步骤不一定都是同步的。集合点是在脚本的某处设置一个标记。当有虚拟用户运行到这个标记处时，停下等待，直到所有的用户都达到这个标记处时，再一同进行下面的步骤，这样能够用最大的用户并发去做下面的操作，就像集合再前进一样。集合点之名由此而得。集合点主要用于对关键步骤的加压。

2.插入集合点的目的

集合点的用处对于LoadRunner来说意义非常大，它可以设置多个虚拟用户等待到一个点，同时触发一个事务，以达到模拟真实环境下同时多个用户操作，同时模拟负载,实现性能测试的最终目的。由此可见，插入集合点主要是为了衡量在加重负载的情况下服务器的性能情况，从而找到性能瓶颈。可以把集合点理解成是一种特殊情况下的并发。

举例如下：在客户的需求中，可能会要求系统能够承受500人同时提交数据。在LR中可以通过在提交数据操作前面加入集合点，当虚拟用户运行到提交数据的集合点时，LR就会检查同时有多少用户运行到集合点，如果我们设定脚本运行的虚拟用户数为1000，等到这1000个虚拟用户都运行到集合点后，就会触发同时进行提交数据的操作，从而能够测试系统能够对于这1000个用户提交数据的响应情况，以此来看系统是否满足客户的该点需求。

事务：就是用户某一步或者某几步操作的集合。当我们需要通过某一步或是某几步操作从而衡量服务器的性能的时候，这时我们就把这些操作设置成一个事务，当事务开始执行的时候lr就开始计时当事务运行结束计时停止，执行事务的时间会在在最后的结果中显示出来。

集合点一般是跟事务结合使用的，不要把集合点设置到事物里面，因为那样的话脚本等待的时间都计算在事务的时间内，进行压力测试的时候查看响应时间就会有一定的偏差。集合点应插入到事务开始的前面，这样在这个地方达到用户的数量后同时执行下面的事务才能测试出多个用户能否同时执行某一操作。

实例：在测试查询编号这个功能，需要在点击查询时设置事务跟集合点

方法一：先设置集合点再设置事务，压20个用户时平均响应时间为16.400

方法二：先设置事务再设置集合点，压20个用户时平均响应时间为0.799

在脚本中直接添加：

lr_rendezvous("集合点名称");

如果脚本中设置了集合点，在conntrol的场景中Scenario/Rendezvous集合功能点会亮(没有则是灰色)。就可以来设置虚拟用户集合的方式。

如果脚本之前没有集合点，后面加进去的，已经加载在场景了要进行刷新，获取最新脚本。

Controller的Scenario Groups中，有个按钮Details，进去之后会有Refresh按钮，有刷新脚本和运行设置两项集合点设置策略Policy：总共有3种

1．当百分之多少的用户到达集合点时脚本继续。2．当百分之多少的运行用户到达集合点时脚本继续。

3．多少个用户到达集合点时脚本继续。

说明：其中1跟2两种只针对设置了多少分钟启动多少用户，如果一开始就加载所有用户就没有什么区别

这3个策略的区别在于：假设脚本由100个用户来运行，但100个用户并不是一开始就共同运行的。假设每隔1分钟添加10个用户，也就是说10分钟后系统才有100个在线用户。这里100就是指系统访问的所有用户数，而不同时间的在线用户数是不同的。设置的集合点策略百分比均为100%。在场景运行时，当Vuser脚本运行到集合点函数时，该虚拟用户会进入集合点状态直到集合点策略满足后才释放。策略1是指当全部用户都运行到了集合点函数才释放集合，让这100个用户并发运行后面的脚本。策略2是指当前时间如果只有10个用户在线，那么只需要这10个用户都运行到了集合点函数就释放集合，让这10个用户并发运行后面的脚本。策略3就比较好理解了，当到达集合点的用户数达到自己设置的数量后就释放等待，并发运行后面的脚本。可以在多个脚本上设置相同的集合点名称来实现多个脚本同时并发的效果。

设置集合点策略时还有一个集合点超时

在脚本运行时，每个虚拟用户到达集合点时都会去检查一下集合点的策略设置，如果不满足，那么就在集合状态等待，直到集合点策略满足后，才运行下一步操作。但是可能存在前一个虚拟用户和后一个虚拟用户达到集合点的时间间隔非常长的情况，所以需要指定一个超时的时间，如果超过这个时间就不等待迟到的虚拟用户了。

超时时间是指虚拟用户之间的时间差，当出现两个虚拟用户到达集合点的时间差超过设定的超时时间时，所有在集合点处于等待状态中的用户将全部释放。