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

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

　　先来看一个应用系统的结构图，以下所示：

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

　　接下来咱们来看看关于并发用户和集合点的定义：

　　并发用户：通俗意义上讲就是同时操做的用户，固然这个“同时”能够理解为同一时间段，还能够理解为同一时间点，固然若是说并发就是同一时间点上同时操做的用户，这样理解没有错误，但对于实际状况来说，是没有严格意义上的并发执行的，就如同进程和线程关系同样，在某一个点严格上讲就只有一我的获得执行的权利。

　　集合点：用以同步虚拟用户，以便刚好在同一时刻执行任务。这个从概念上来说，其实也是比较模糊，正由于模糊，使用才值得去深刻探讨。对于LoadRunner来讲，集合点只是一种策略，而这个策略也会有不少规则，由于实际状况中并不是全部用户都会同时到达集合点，上面的那个结构图就能解释这个误解，由于从客户端发出到网络、中间件、应用层再到数据库，这其中的每个环节都有延时，也就是说不可能全部的用户都能到达所谓的集合点，才开始同时执行操做。

　　从上面的两个概念的理解来说，有人就会思考，并发用户和集合点到底有没有关系，这才是关键。固然这个就要看需求是什么了，因此说不少时候咱们误用集合点和并发用户，其实根本缘由在于对需求的理解，需求自己都没有搞清楚他想实现的场景，获得什么样的结果。固然，咱们只能感慨需求并是专业的技术人员，至少咱们大多数人碰到的需求都不必定是技术出身，因此他们不明白，咱们就不能装忽悠，否则结果就确定不符合实际了。

　　一般状况下，咱们会获得用户这样的需求“本系统要达到并发用户200”，这种需求从严格意义上来说是不合格的，由于对于一个系统来讲有不少个功能，好比系统登陆、注册、查询、删除等等，是要求登陆达到200，仍是全部功能总共达到200，由于当用户进入系统以后，有些用户在执行注册，有些用户在执行查询，是否能够并行操做，也是所谓的并发，因此说要理解集合点和并发数，从根本上就应该更清晰的理解业务流程，只有把业务分析清楚了，方才能够合理的使用集合点，正确的理解并发用户数。

　　固然，就我我的来说，我是不多使用集合点的，由于经过LoadRunner的理解，我认为LoadRunner自己就已经在模拟实现一个并发的过程，而增长集合点设置只是为了并实现严格意义上的所谓的并发，而实际是这个集合点的设置也并不是绝对达到了这个目的，结构中的过程就能够证实。固然为此我也经过一些实例来作验证，如下是对Mercury web Tours网站首页，录制访问过程，脚本以下：

　　脚本 1：设置集合点

Action()
{
lr_rendezvous("同步访问web页面");

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;
}

　　脚本 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个用户同时进行登陆操做。由此能够说明，任何需求的提出都必须从实际环境来考虑，咱们在设置场景时也必须反映出实际状况，才能模拟出更接近真实的场景，得出来的结果才更有价值。

　　固然，性能测试的执行应该是有目的，一般是为了调优，也有的是为了评测

　　在以评测为目的的性能测试中，用户更关心的是业务上的并发，实际上是真实业务场景的并发状况，这种状况下就不须要设置集合点了。

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

　　以上纯属我的理解