探讨LoadRunner的并发用户和集合点

王磊

摘 要 在现行阶段很多人士比较热衷于使用集合点，从概念上认为要得到并发用户就必须设置集合点，认为在执行一个压力测试脚本时，设置了集合点才算是有效的并发用户，没有设置结合点，就认为可能这个就不能准确的代表并发用户数。对并发用户和集合点，缺乏对系统整个过程的分析，这其中涉及到的知识包括网络、协议、中间件、数据库、应用层以及缓冲区和缓存等等，当然还与硬件资源CPU队列和内存等有着千丝万缕的联系。

关键词 LoadRunner 并发用户 集合点

中图分类号：TP391.4 文献标识码：A

1关于并发用户和集合点的定义

并发用户：通俗意义上讲就是同时操作的用户，当然这个“同时”可以理解为同一时间段，还可以理解为同一时间点。如果说并发就是同一时间点上同时操作的用户，这样理解没有错误，但对于实际情况来讲，是没有严格意义上的并发执行的，就如同进程和线程关系一样，在某一个点严格上讲就只有一个人得到执行的权利。集合点：用以同步虚拟用户，以便恰好在同一时刻执行任务。这个从概念上来讲，其实也是比较模糊，正因为模糊，使用才值得去深入探讨。对于LoadRunner来说，集合点只是一种策略，而这个策略也会有很多规则，因为实际情况中并非所有用户都会同时到达集合点，因为从客户端发出到网络、中间件、应用层再到数据库，这其中的每一个环节都有延时，也就是说不可能所有的用户都能到达所谓的集合点，才开始同时执行操作。

2关于并发用户和集合点的个人理解

从上面两个概念的理解来讲，有人就会思考，并发用户和集合点到底有没有关系，这才是关键。当然这个就要看需求是什么了，所以说很多时候人们误用集合点和并发用户，其实根本原因在于对需求的理解，需求本身都没有搞清楚想实现的场景，得到什么样的结果。当然需求并不是专业的技术人员，至少大多数人碰到的需求都不一定是技术出身，所以他们不明白，我们就不能装忽悠，不然结果就肯定不符合实际了。通常情况下，我们会得到用户这样的需求“本系统要达到并发用户200”，这种需求从严格意义上来讲是不合格的，因为对于一个系统来说有很多个功能，比如系统登录、注册、查询、删除等等，是要求登录达到200，还是所有功能总共达到200，因为当用户进入系统之后，有些用户在执行注册，有些用户在执行查询，是否可以并行操作，也是所谓的并发，所以说要理解集合点和并发数，从根本上就应该更清晰的理解业务流程，只有把业务分析清楚了，方才可以合理的使用集合点，正确的理解并发用户数。通过对LoadRunner的理解，LoadRunner本身就已经在模拟实现一个并发的过程，而增加集合点设置只是为了并实现严格意义上的所谓的并发，而实际是这个集合点的设置也并非绝对达到了这个目的，结构中的过程就可以证明。

3设置脚本集合点和不设置检查点的对比

在相同场景实际中执行两个脚本之后，发现其响应时间误差很小。在其他项目中包括C/S和B/S都有的，很多项目都实践过，并不是集合点在我们的性能测试中没有作用，如果没有作用相信设计LoadRunner的公司也不会给出来，而是要理解如何选择去用它，这才是关键。之前就讲到过，在一些业务流程比较复杂的应用程序测试中，就必须要使用集合点，比如一个企业系统中业务是这样的：用户登录进入之后，一部分人在完善个人资料，一部分人在查询数据，另一部分人在执行删除操作，还有一部分来发送消息等等。就这样的一个业务中，在模拟执行性能测試时，就必须明确并发用户跟集合点的关系，在实际录制脚本的时候，就需要把这个业务分割成多个事务，然后分别对各个不同的事务设置集合点，为什么此时要使用集合点呢，因为我们必须分析出每一个事务的并发情况，加入200个用户进去之后，就这样放任去这200个用户自由去操作，就不能判断出查询并发数多少、删除并发数多少、发送消息的并发又是多少，因为进入系统之后，没办法确定200个用户都同时干了些什么，所以此处才是集合点使用最合理的地方。至于使用集合点，也源于此，因为通常情况我们主要是对单一业务进行压力测试，比如登录或者是注册，单一功能就如同上面的那个访问web页面一样，脚本只有一个操作，此时对于LoadRunner来讲，其实有没有设置集合点效果不大，而且为了模拟能更加接近实际情况，也是需要做实际分析的。

4结论

总之，性能测试的执行应该是有目的的，通常是为了调优，也有的是为了评测，在以评测为目的的性能测试中，用户更关心的是业务上的并发，其实是真实业务场景的并发情况，这种情况下就不需要设置集合点了。集合点是一种特殊情况下的并发，通常是在以调优为目的的性能测试中才会用得到，主要是为了有针对性地进行施压，以便找到性能瓶颈。