探讨探讨LoadRunner的并发用户和集合点的并发用户和集合点
近来跟踪一个项目,发现同事们在执行性能测试时,比较热衷于使用集合点,从概念上认为要得到并发用户就必须设
置集合点,认为在执行一个压力测试脚本时,设置了集合点才算是有效的并发用户,没有设置结合点,就认为可能这
个就不能准确的代表并发用户数。当前我并反对这个观点,不过却让我有一种疑虑,促使我想更深入的理解并发用户
和集合点,我相信大多数进入性能测试研究领域的朋友都应该有疑惑,主要原因我觉得还是由于不能深入理解
LoadRunner的实现原理,而且缺乏对系统整个过程的分析,其中这里面涉及到的知识包括网络、协议、中间件、数据
库、应用层以及缓冲区和缓存等等,当然还与硬件资源CPU队列和内存等有着千丝万缕的联系。所以说要成为一个优
秀的性能测试人员,真还不一个容易的过程,是需要长时间积累和学习的,只有通过大量的项目实践和分析,最后再
总结于思想,才有可能成为这个领域的专家,当然也希望真正想把性能测试做好的朋友都能为此将不懈努力,乐于分
享和讨论。
先来看一个应用系统的结构图,如下所示:先来看一个应用系统的结构图,如下所示:
这个图源于小布老师的视频中,比较直观、简洁地反映了一个应用系统的运行过程,其中包括客户端、网络、应用服
务器和数据库服务器,其中每一个环节都是在执行性能测试分析中必不可少的元素,结构图中也合理得分析出了响应
时间的处理过程,当请求从客户端发出之后到最后返回到客户端,这个过程中每一个环节的处理都有可能最后成为系
统运行中的性能瓶颈,所以可见对系统整体结构的理解是何等重要。
接下来我们来看看关于并发用户和集合点的定义:接下来我们来看看关于并发用户和集合点的定义:
并发用户:并发用户:通俗意义上讲就是同时操作的用户,当然这个“同时”可以理解为同一时间段,还可以理解为同一时间点,当
然如果说并发就是同一时间点上同时操作的用户,这样理解没有错误,但对于实际情况来讲,是没有严格意义上的并
发执行的,就如同进程和线程关系一样,在某一个点严格上讲就只有一个人得到执行的权利。
集合点:集合点:用以同步虚拟用户,以便恰好在同一时刻执行任务。这个从概念上来讲,其实也是比较模糊,正因为模糊,
使用才值得去深入探讨。对于LoadRunner来说,集合点只是一种策略,而这个策略也会有很多规则,因为实际情况中
并非所有用户都会同时到达集合点,上面的那个结构图就能解释这个误解,因为从客户端发出到网络、中间件、应用
层再到数据库,这其中的每一个环节都有延时,也就是说不可能所有的用户都能到达所谓的集合点,才开始同时执行
操作。
从上面的两个概念的理解来讲,有人就会思考,并发用户和集合点到底有没有关系,这才是关键。当然这个就要看需
求是什么了,所以说很多时候我们误用集合点和并发用户,其实根本原因在于对需求的理解,需求本身都没有搞清楚
他想实现的场景,得到什么样的结果。当然,我们只能感慨需求并是专业的技术人员,至少我们大多数人碰到的需求
都不一定是技术出身,所以他们不明白,我们就不能装忽悠,不然结果就肯定不符合实际了。
通常情况下,我们会得到用户这样的需求“本系统要达到并发用户200”,这种需求从严格意义上来讲是不合格的,因为
对于一个系统来说有很多个功能,比如系统登录、注册、查询、删除等等,是要求登录达到200,还是所有功能总共达
到200,因为当用户进入系统之后,有些用户在执行注册,有些用户在执行查询,是否可以并行操作,也是所谓的并
发,所以说要理解集合点和并发数,从根本上就应该更清晰的理解业务流程,只有把业务分析清楚了,方才可以合理
的使用集合点,正确的理解并发用户数。
当然,就我个人来讲,我是很少使用集合点的,因为通过LoadRunner的理解,我认为LoadRunner本身就已经在模拟
实现一个并发的过程,而增加集合点设置只是为了并实现严格意义上的所谓的并发,而实际是这个集合点的设置也并
非绝对达到了这个目的,结构中的过程就可以证明。当然为此我也通过一些实例来做验证,以下是对Mercury web
Tours网站首页,录制访问过程,脚本如下:
评论0