前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >【性能工具】LoadRunner之集合点详解

【性能工具】LoadRunner之集合点详解

作者头像
Luga Lee
发布2022-03-25 13:57:41
1.5K0
发布2022-03-25 13:57:41
举报
文章被收录于专栏:架构驿站

集合点函数可以帮助我们生成有效可控的并发操作。虽然在Controller中多用户负载的Vuser是一起开始运行脚本的,但是由于计算机的串行处理机制,脚本的运行随着时间的推移,并不能完全达到同步。这个时候需要手工的方式让用户在同一时间点上进行操作来测试系统并发处理的能力,而集合点函数就能实现这个功能。集合点只需要在脚本中插入lr_rendezvous()函数即可。打开Insert菜单下的Rendezvous选项,如图3.167所示。

在弹出的对话框中输入集合点名称run,确定后即可得到对应的脚本:

lr_rendezvous("run");

引号内的就是集合点名称,当脚本在多用户运行的情况下,每次运行到这个函数都会查看一下集合点的策略来决定是等待还是继续运行。集合点的设置内容存放在场景的设置中,当脚本中有集合点函数时,场景中的集合点设置功能就可以访问,如图3.168所示。

图3.167 添加集合点函数

打开场景菜单下的集合点后,可以为集合点进行设置,包括哪些用户使用该集合点、集合点是否有效等,如图3.169所示。

如果脚本中没有集合点,那么场景中的Scenario/Rendezvous集合点功能将会是灰色显示。

集合点策略用来设置虚拟用户集合的方式,打开Policy对话框,如图3.170所示。

集合点提供了以下3种策略:

1.当百分之多少的用户到达集合点时脚本继续。

2.当百分之多少的运行用户到达集合点时脚本继续。

3.多少个用户到达集合点时脚本继续。

这3个策略的区别在于:假设脚本由100个用户来运行,但100个用户并不是一开始就共同运行的。假设每隔1分钟添加10个用户,也就是说10分钟后系统才有100个在线用户。这里100就是指系统访问的所有用户数,而不同时间的在线用户数是不同的。设置的集合点策略百分比均为100%。

在场景运行时,当Vuser脚本运行到集合点函数时,该虚拟用户会进入集合点状态直到集合点策略满足后才释放。

策略1是指当全部用户都运行到了集合点函数才释放集合,让这100个用户并发运行后面的脚本。

策略2是指当前时间如果只有10个用户在线,那么只需要这10个用户都运行到了集合点函数就释放集合,让这10个用户并发运行后面的脚本。

策略3就比较好理解了,当到达集合点的用户数达到自己设置的数量后就释放等待,并发运行后面的脚本。

可以在多个脚本上设置相同的集合点名称来实现多个脚本同时并发的效果。

集合点超时

在脚本运行时,每个虚拟用户到达集合点时都会去检查一下集合点的策略设置,如果不满足,那么就在集合状态等待,直到集合点策略满足后,才运行下一步操作。但是可能存在前一个虚拟用户和后一个虚拟用户达到集合点的时间间隔非常长的情况,所以需要指定一个超时的时间,如果超过这个时间就不等待迟到的虚拟用户了。

超时时间是指虚拟用户之间的时间差,当出现两个虚拟用户到达集合点的时间差超过设定的超时时间时,所有在集合点处于等待状态中的用户将全部释放。

集合点和事务

集合点应该放在事务外,如果事务内存在集合点,那么虚拟用户在集合点等待的过程也会被算入事务时间,导致早进入集合点的用户的响应时间有误。

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

并发用户:通俗意义上讲就是同时操作的用户,当然这个“同时”可以理解为同一时间段,还可以理解为同一时间点,当然如果说并发就是同一时间点上同时操作的用户,这样理解没有错误,但对于实际情况来讲,是没有严格意义上的并发执行的,就如同进程和线程关系一样,在某一个点严格上讲就只有一个人得到执行的权利。 集合点:用以同步虚拟用户,以便恰好在同一时刻执行任务。这个从概念上来讲,其实也是比较模糊,正因为模糊,使用才值得去深入探讨。对于LoadRunner来说,集合点只是一种策略,而这个策略也会有很多规则,因为实际情况中并非所有用户都会同时到达集合点,上面的那个结构图就能解释这个误解,因为从客户端发出到网络、中间件、应用层再到数据库,这其中的每一个环节都有延时,也就是说不可能所有的用户都能到达所谓的集合点,才开始同时执行操作。 从上面的两个概念的理解来讲,有人就会思考,并发用户和集合点到底有没有关系,这才是关键。当然这个就要看需求是什么了,所以说很多时候我们误用集合点和并发用户,其实根本原因在于对需求的理解,需求本身都没有搞清楚他想实现的场景,得到什么样的结果。当然,我们只能感慨需求并是专业的技术人员,至少我们大多数人碰到的需求都不一定是技术出身,所以他们不明白,我们就不能装忽悠,不然结果就肯定不符合实际了。

通常情况下,我们会得到用户这样的需求“本系统要达到并发用户200”,这种需求从严格意义上来讲是不合格的,因为对于一个系统来说有很多个功能,比如系统登录、注册、查询、删除等等,是要求登录达到200,还是所有功能总共达到200,因为当用户进入系统之后,有些用户在执行注册,有些用户在执行查询,是否可以并行操作,也是所谓的并发,所以说要理解集合点和并发数,从根本上就应该更清晰的理解业务流程,只有把业务分析清楚了,方才可以合理的使用集合点,正确的理解并发用户数。

以下是对Mercury web Tours网站首页,录制访问过程,脚本如下:

脚本 1:设置集合点

Action() {

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

lr_start_transaction("start");

web_url("mercuryWebTours", "URL=http://192.168.3.34:1080/mercuryWebTours/", "Resource=0", "RecContentType=text/html", "Referer=", "Snapshot=t1.inf", "Mode=HTML", LAST);

lr_end_transaction("start", LR_AUTO);

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

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2015-03-22,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 架构驿站 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
消息队列 TDMQ
消息队列 TDMQ (Tencent Distributed Message Queue)是腾讯基于 Apache Pulsar 自研的一个云原生消息中间件系列,其中包含兼容Pulsar、RabbitMQ、RocketMQ 等协议的消息队列子产品,得益于其底层计算与存储分离的架构,TDMQ 具备良好的弹性伸缩以及故障恢复能力。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档