通常情况下，我们会得到用户这样的需求“本系统要达到并发用户200”，这种需求从严格意义上来讲是不合格的，因为对于一个系统来说有很多个功能，比如系统登录、注册、查询、删除等等，是要求登录达到200，还是所有功能总共达到200，因为当用户进入系统之后，有些用户在执行注册，有些用户在执行查询，是否可以并行操作，也是所谓的并发，所以说要理解集合点和并发数，从根本上应该更清晰的理解业务流程，只有把业务分析清楚了，方才可以合理的使用集合点，正确的理解并发用户数。
　　当然，我个人来讲，我是很少使用集合点的，因为通过LoadRunner的理解，我认为LoadRunner本身已经在模拟实现一个并发的过程，而增加集合点设置只是为了并实现严格意义上的所谓的并发，而实际是这个集合点的设置也并非达到了这个目的，结构中的过程可以证明。当然为此我也通过一些实例来做验证，以下是对Mercury web Tours网站首页，录制访问过程，脚本如下：
　　脚本1：设置集合点
　　Action()
　　{
　　lr_rendezvous("同步访问web页面");
　　lr_start_transaction("start");
　　web_url("mercuryWebTours"，
　　"URL=http://192.168.3.34:1080/mercuryWebTours/"，
　　"Resource=0"，
　　"RecContentType=text/html"，
　　"Referer="，
　　"Snapshot=t1.inf"，
　　"Mode=HTML"，
　　LAST);
　　lr_end_transaction("start"，LR_AUTO);
　　return 0;
　　}
　　脚本2：不设置集合点
　　Action()
　　{
　　web_url("mercuryWebTours"，
　　"URL=http://192.168.3.34:1080/mercuryWebTours/"，
　　"Resource=0"，
　　"RecContentType=text/html"，
　　"Referer="，
　　"Snapshot=t1.inf"，
　　"Mode=HTML"，
　　LAST);
　　return 0;
　　}
　　在相同场景实际中执行两个脚本之后，发现其响应时间其实误差很小。当然，这只是我实践中的一个，近期做的其他项目中，包括C/S和B/S都有的，我也都有实践过，期待有兴趣的朋友也可以实践验证哈，分享结论。
　　以上我只是想表达的一个观点是，并不是集合点在我们的性能测试中没有作用，如果没有作用我相信设计LoadRunner的公司也不会给出来，而是要理解如何选择去用它，这才是关键。之前我们讲到过，在一些业务流程比较复杂的应用程序测试中，我们必须要使用集合点，比如一个企业系统中业务是这样的：用户登录进入之后，一部分人在完善个人资料，一部分人在查询数据，另一部分人在执行删除操作，还有一部分来发送消息等等。这样的一个业务中，在模拟执行性能测试时，必须明确并发用户跟集合点的关系，在实际录制脚本的时候，我们需要把这个业务分割成多个事务，然后分别对各个不同的事务要设置集合点，为什么此时要使用集合点呢，因为我们必须分析出每一个事务的并发情况，加入200个用户进去之后，我们这样放任去这200个用户自由去操作，不能判断出查询并发数多少、删除并发数多少、发送消息的并发又是多少，因为进入系统之后，没办法确定200个用户都同时干了些什么，所以此处才是集合点使用合理的地方。至于，我为什么很少使用集合点，也源于此，因为通常情况我们主要是对单一业务进行压力测试，比如登录或者是注册，单一功能如同上面的那个访问web页面一样，脚本只有一个操作，此时对于LoadRunner来讲，其实有没有设置集合点效果不大，而且为了模拟能更加接近去实际情况，当然这也是要做实际分析的。这里我还要个举例子，比如，一个OA系统，要求并发用户数200，而我们的场景设置是这样的，200个并发用户平均每10s加载5个用户，大约运行半小时，此时执行的场景，我们可以结合实际情况进行分析：根据实际情况得出，通常登录OA系统的的用户大部分都在早上上班9：00～9：30，此时是一个时间段，而并非一个时间点，使用我们的模拟场景是完全符合实际需求的，所以得出结论是在30分钟的时间内，我们的OA系统可以允许200个用户同时进行登录操作。由此可以说明，任何需求的提出都必须从实际环境来考虑，我们在设置场景时也必须反映出实际情况，才能模拟出更接近真实的场景，得出来的结果才更有价值。
　　当然，性能测试的执行应该是有目的，通常是为了调优，也有的是为了评测
　　在以评测为目的的性能测试中，用户更关心的是业务上的并发，其实是真实业务场景的并发情况，这种情况下不需要设置集合点了。
　　集合点是一种特殊情况下的并发，通常是在以调优为目的的性能测试中才会用得到，主要是为了有针对性地进行施压，以便找到性能瓶颈。