近来跟踪一个项目，发现同事们在执行性能测试时，比较热衷于使用集合点，从概念上认为要得到并发用户必须设置集合点，认为在执行一个压力测试脚本时，设置了集合点才算是有效的并发用户，没有设置结合点，认为可能这个不能准确的代表并发用户数。当前我并反对这个观点，不过却让我有一种疑虑，促使我想更深入的理解并发用户和集合点，我相信大多数进入性能测试研究领域的朋友都应该有疑惑，主要原因我觉得还是由于不能深入理解LoadRunner的实现原理，而且缺乏对系统整个过程的分析，其中这里面涉及到的知识包括网络、协议、中间件、数据库、应用层以及缓冲区和缓存等等，当然还与硬件资源CPU队列和内存等有着千丝万缕的联系。所以说要成为一个的性能测试人员，真还不一个容易的过程，是需要长时间积累和学习的，只有通过大量的项目实践和分析，后再总结于思想，才有可能成为这个领域的专家，当然也希望真正想把性能测试做好的朋友都能为此将不懈努力，乐于分享和讨论。
　　先来看一个应用系统的结构图，如下所示：

　　这个图源于小布老师的视频中，比较直观、简洁地反映了一个应用系统的运行过程，其中包括客户端、网络、应用服务器和数据库服务器，其中每一个环节都是在执行性能测试分析中必不可少的元素，结构图中也合理得分析出了响应时间的处理过程，当请求从客户端发出之后到后返回到客户端，这个过程中每一个环节的处理都有可能后成为系统运行中的性能瓶颈，所以可见对系统整体结构的理解是何等重要。
　　接下来我们来看看关于并发用户和集合点的定义：
　　并发用户：通俗意义上讲是同时操作的用户，当然这个“同时”可以理解为同一时间段，还可以理解为同一时间点，当然如果说并发是同一时间点上同时操作的用户，这样理解没有错误，但对于实际情况来讲，是没有严格意义上的并发执行的，如同进程和线程关系一样，在某一个点严格上讲只有一个人得到执行的权利。
　　集合点：用以同步虚拟用户，以便恰好在同一时刻执行任务。这个从概念上来讲，其实也是比较模糊，正因为模糊，使用才值得去深入探讨。对于LoadRunner来说，集合点只是一种策略，而这个策略也会有很多规则，因为实际情况中并非所有用户都会同时到达集合点，上面的那个结构图能解释这个误解，因为从客户端发出到网络、中间件、应用层再到数据库，这其中的每一个环节都有延时，也是说不可能所有的用户都能到达所谓的集合点，才开始同时执行操作。
　　从上面的两个概念的理解来讲，有人会思考，并发用户和集合点到底有没有关系，这才是关键。当然这个要看需求是什么了，所以说很多时候我们误用集合点和并发用户，其实根本原因在于对需求的理解，需求本身都没有搞清楚他想实现的场景，得到什么样的结果。当然，我们只能感慨需求并是专业的技术人员，至少我们大多数人碰到的需求都不一定是技术出身，所以他们不明白，我们不能装忽悠，不然结果肯定不符合实际了。