Loadrunner的并发用户数和集合点分析

林克强，赵秀娟

(1.中国电子科技集团公司第五十四研究所，河北石家庄050081;2.石药集团河北中诚医药有限公司，河北石家庄050081)

0 引言

系统的性能是一个很大的概念，覆盖面非常广泛，对一个软件系统而言，包括执行效率、资源占用、稳定性、安全性、兼容性、可扩展性以及可靠性等。负载压力是系统性能的一个重要方面，是指在一定约束条件下测试系统所能承受的并发用户量、运行时间、数据量，以确定系统所能承受的最大负载压力［3］。在一个大型应用系统里，某些业务操作对特定角色用户来讲存在很大的同时操作的可能性。客户端大量的并发操作提高了网络的吞吐量，加剧了服务器资源互斥访问冲突，加大了数据库死锁的可能。这样的负载压力轻则会导致系统性能低下，重则会对系统造成破坏，给用户带来经济损失。因此负载压力测试对于保证系统的性能是非常关键的。基于Loadrunner的并发性能测试需要确定并发用户数和设置集合点，以达到在服务器上创建密集的用户负载。

1 并发用户和集合点

关于并发用户和集合点的定义如下:

并发用户:通过模拟用户的并发访问，测试多用户同时访问同一个应用、同一个模块或者数据记录时是否存在死锁或者其他性能问题［2］。当然这个“同时”可以理解为同一时间段，还可以理解为同一时间点，当然如果说并发就是同一时间点上同时操作的用户，这样理解没有错误，但对于实际情况来讲，是没有严格意义上的并发执行的，就如同进程和线程关系一样，在某一个点严格上讲就只有一个人得到执行的权利。

集合点:用以同步虚拟用户以便恰好在同一时刻执行任务。可以在服务器上创建密集的用户负载［1］。对于Loadrunner来说，集合点只是一种策略，而这个策略也会有很多规则，因为实际情况中并非所有用户都会同时到达集合点，因为从客户端发出到网络、中间件、应用层再到数据库，这其中的每一个环节都有延时，也就是说不可能所有的用户都能到达所谓的集合点才开始同时执行操作。

从上面2个概念的理解来讲，有人就会思考，并发用户和集合点到底有没有关系，这才是关键。当然这个就要看需求是什么了，所以在很多时候误用集合点和并发用户，其实根本原因在于对需求的理解。

2 应用系统组成

从概念上认为要得到并发用户就必须设置集合点，认为在执行一个压力测试脚本时，设置了集合点才算是有效的并发用户，没有设置集合点，就认为可能这个就不能准确地代表并发用户数。

先来看一个应用系统的结构图，如图1所示。

图1 应用系统结构图

图1比较直观、简洁地反映了一个应用系统的运行过程，其中包括客户端、网络、应用服务器和数据库服务器，其中每一个环节都是在执行性能测试分析中必不可少的元素，结构图中也合理地分析出了响应时间的处理过程，当请求从客户端发出之后到最后返回客户端，这个过程中每一个环节的处理都有可能最后成为系统运行中的性能瓶颈，所以可见对系统整体结构的理解是何等重要。

2.1 测试构建

假设有一个OA系统，该系统有2 000个使用用户——这就是说，可能使用该OA系统的用户总数是2 000名，这个概念就是“系统用户数”，该系统有一个“在线统计”功能(系统用一个全局变量计数所有已登录的用户)，从在线统计功能中可以得到，最高峰时有500人在线(这个500就是一般所说的“同时在线人数”)，那么，系统的并发用户数是多少呢?

根据对并发用户数的定义，这500就是整个系统使用时最大的业务并发用户数。当然，500这个数值只是表明在最高峰时刻有500个用户登录了系统，并不表示实际服务器承受的压力。因为服务器承受的压力还与具体的用户访问模式相关。例如，在这500个“同时使用系统”的用户中，考察某一个时间点，在这个时间上，假设其中40%的用户在饶有兴致地看系统公告(注意:“看”这个动作是不会对服务端产生任何负担的)，20%的用户在填写复杂的表格(对用户填写的表格来说，只有在“提交”的时刻才会向服务端发送请求，填写过程是不对服务端构成压力的)，20%部分用户在发呆(也就是什么也没有做)，剩下的20%用户在不停地从一个页面跳转到另一个页面——在这种场景下，可以说，只有20%的用户真正对服务器构成了压力。因此，从上面的例子中可以看出，服务器实际承受的压力不只取决于业务并发用户数，还取决于用户的业务场景。

所以说要理解集合点和并发数，从根本上就应该更清晰地理解业务流程，只有把业务分析清楚了，方才可以合理地使用集合点，正确地理解并发用户数。

2.2 测试实践分析

通过Loadrunner的理解，我认为Loadrunner本身就已经在模拟实现一个并发的过程，而增加集合点设置只是为了实现严格意义上的所谓并发，而实际是这个集合点的设置也并非绝对达到了这个目的，结构图中的过程就可以证明。当然，为此也通过一些实例来做验证，以下是对cetcbbs内部论坛首页，录制访问过程，脚本如下:

脚本1:设置集合点

在场景中设置100个并发用户，执行2个脚本之后，可以得到它们的平均事务响应时间，如图2和图3所示，从图中可以看到2个脚本的运行结果相差很小。

图2 脚本1平均事务响应时间

图3 脚本2平均事务响应时间

集合点在性能测试中并不是没有作用，而是要理解如何选择去用它，这才是关键。

在一些业务流程比较复杂的应用程序测试中，就必须要使用集合点。比如一个应用系统中业务是这样的:用户登录进入之后，一部分人在完善资料，一部分人在查询数据，另一部分人在执行删除操作，还有一部分人在发送消息等等。就这样的一个业务中，在模拟执行性能测试时，就必须明确并发用户跟集合点的关系，在实际录制脚本的时候，就需要把这个业务分割成多个事务，然后分别对各个不同的事务设置集合点。

为什么此时要使用集合点呢?因为必须分析出每一个事务的并发情况，加入200个用户进去之后，就这样放任这200个用户自由去操作，就不能判断出查询并发数多少、删除并发数多少、发送消息的并发数又是多少，因为进入系统之后，没办法确定200个用户都同时干了些什么，所以此处才是集合点使用最合理的地方。

通常情况，主要是对单一业务进行压力测试，如登录或者注册，单一功能就如同上面的那个访问web页面一样，脚本只有一个操作，此时对于Loadrunner来讲，其实有没有设置集合点效果不大，而且为了模拟能更加接近实际情况，当然这也是要做实际分析的。

3 结束语

性能测试的执行应该是有目的，通常是为了调优，也有的是为了评测。在以评测为目的的性能测试中，用户更关心的是业务上的并发，其实是真实业务场景的并发情况，这种情况下就不需要设置集合点了。

集合点是一种特殊情况下的并发，通常是在以调优为目的的性能测试中才会用到，主要是为了有针对性的进行施压，以便找到性能瓶颈。

［1］于涌.软件性能测试与LOADRUNNER实战［M］.北京:人民邮电出版社，2008.

［2］段念.软件性能测试过程详解与案例剖析［M］.北京:清华大学出版社，2006.

［3］柳纯录.软件评测师教程［M］.北京:清华大学出版社，2005.