LoadRunner几个重要的概念:事务、集合点、思考时间

在LoadRunner的脚步编写中,有三个重要的概念:事务、集合点、思考时间

  事务:

  事务又称为Transaction,在LoadRunner中的定义如下:An end-to-end(browser-to-browser)  measurement of one or more user actions within action  file。中文理解如下:事务(Transaction)是这样一个点,我们为了衡量某个action的性能,需要在action的开始和结束位置插入这样一个范围,这就定义了一个transaction。

  事务的作用:LoadRunner运行到该事务的开始点时,LoadRunner就会开始计时,直到运行到该事务的结束点,计时结束。这个事务的运行时间在LoadRunner的运行结果中会有反映。通俗的讲LoadRunner中的事务就是一个计时标识,LoadRunner在运行过程中一旦发现事务的开始标识,就开始计时,一旦发现事务的结束表示,则计时结束,这个过程中得到的时间即为一个事务时间。通常事务时间所反映的是一个操作过程的响应时间。

  下面我们说说为什么在LoadRunner中使用事务。为什么使用事务的原因是多种多样的,总结下来如下五点所示:

  1、事务是LoadRunner度量系统性能指标的唯一手段;(没有事务则没有办法衡量系统的响应时间,也许有人说LoadRunner可以通过编程来计时得到,不错如果你编程能力够强是能够实现的,但肯定不如LoadRunner中的事务用的简单而且方便)

  2、事务能够用于度量高风险业务流程的性能指标;

  3、事务能够度量在一组操作中每一步的性能指标;

  4、通过事务计时实现了不同压力负载下的性能指标对比;

  5、通过事务计时可以帮助定位性能瓶颈;

  从性能测试的  角度出发,我们需要知道不同的操作所花费的时间,这样我们就可以衡量不同的操作对被测系统所造成的影响,那么我们如何知道不同的操作所花费的时间,这就用  到了事务,我们在操作之前插入一个事务开始标识,在操作完成后插入一个事务结束表示,这样我们就知道了这个操作所花费的时间。

  集合点:

  执行负载测试时,需要模拟系统上有较重的用户负载。要实现此操作,可以同步 Vuser 以便恰好在同一时刻执行任务。通过创建集合点,可以配置多个  Vuser 同时执行操作。当某个 Vuser 到达该集合点时,将进行等待,直到参与该集合的全部 Vuser 都到达。指定数量的 Vuser  均到达后,释放所有这些 Vuser。

  可通过将集合点插入到 Vuser 脚本来指定会合位置。在 Vuser 执行脚本并遇到集合点时,脚本将暂停执行,Vuser 将等待 Controller  或控制台的允许以继续执行。Vuser 从集合释放后,将执行脚本中的下一个任务。

  注意:只能向 Action 部分(而不是 init 或 end 部分)添加集合。

  插入集合点是为了衡量在加重负载的情况下的性能情况。在计划中,可能会要求系统能够承受1000 人同时提交数据,在LoadRunner  中可以通过在提交数据操作前面加入集合点,这样当虚拟用户运行到提交数据的集合点时,LoadRunner 就会检查同时有多少用户运行到集合点,如果不到1000  人,LoadRunner 就会命令已经到集合点的用户在此等待,当在集合点等待的用户达到1000 人时,LoadRunner 命令1000  人同时去提交数据,从而达到计划中的需求

  思考时间:

  loadrunner 思考时间(think-time)的理解

  经常碰到很多网友在问性能测试思考时间的设置,有的设置是默认录制的值,有的是觉得在压力测试时要去掉思考时间这样服务器压力才大,各人的理解不一样其实在测试时是要适当加入思考时间但是时间不能太长一般都是1--5秒内。下面是对思考时间的一些说法。

  在录制脚本时 我们一般会选择记录思考时间 record think  time,Loadrunner做为性能测试工具,录制时记录的是客户端和服务端的交互,如果要精确模拟  用户的行为,那么客户操作客户端时花费了很多时间要怎么模拟呢?录入填写提交的内容,从列表中下拉搜索选择特定的值等,这时LOADRUNNER 不会记录用户  的客户端操作,而是记录了用户这段时间,成为思考时间(Think-time),因为用户的这些客户端操作不会影响服务端,只是让服务器端在这段时间内没有请求而已。,所以加入思考时间就能模拟出熟练的或者生疏的用户操作,接近实际对于服务端的压力。

  Vuser  思考时间模拟实际用户在不同操作之间等待的时间。例如,当用户收到来自服务器的数据时,可能要等待几秒钟查看数据,然后再做出响应。这种延迟就称为“思考时间”。VuGen  使用 lr_think_time 函数将思考时间值录制到 Vuser 脚本中。以下录制的函数指明用户等待了 8 秒钟才执行下一个操作:

  lr_think_time(8);

  当您运行了 Vuser 脚本并且 Vuser 遇到了上述 lr_think_time 语句时,默认情况下,Vuser 将等待 8  秒钟后再执行下一个操作。可以使用思考时间运行时设置来影响运行脚本时 Vuser 使用录制思考时间的方式。

原文转自:http://www.ltesting.net

时间: 2024-10-24 06:28:42

LoadRunner几个重要的概念:事务、集合点、思考时间的相关文章

性能测试-7.事务、检查、关联、思考时间、集合点

本章目录: 事务及事务状态 检查点 思考时间 集合点 关联 一.事务: 一个或多个业务操作的集合,协助统计业务的时间.TPS就是每秒钟所处理的事务数. 在要添加的函数前后插入事务开始和结束.运行后日志会显示事务的结果和运行时间. 事务=响应时间+传输时间+网络延迟时间 函数自身的时间也会有 二.检查点 检查点:预期值与实际值比较  实际值在所定义的函数下面语句的服务器的响应包里 检查点支持参数化,性能测试中,不建议做过,会消耗时间(对服务器没有负载) 三.思考时间 lr_think_time(1

性能基础知识学习之四---事务,思考时间,检查点,集合点和手写lr接口

一.事物,思考时间,检查点,集合点 1.事务 lr里面的事物是lr运行脚本的基础.lr里面 要测试的三个维度都以事物为单位,所以一定要有事物.事务的概念贯穿loadrunner的使用,比如我们说的响应时间其实是事务的的相应时间;tps,每秒中处理的事务数.当脚本跑完之后没有响应时间,导致此种情况之一就是没定义事务. 而在录脚本时: 1.在录脚本是要添加事务 2.添加事务是为了准确的测出相应请求的响应时间,尽量保证每一个事务中只有一个请求.但当录制脚本的时候,在录制HTML脚本时,由于一个HTML

LoadRunner 思考时间与事务响应时间的区别与关系

LoadRunner 思考时间与事务响应时间的区别与关系   思考时间lr_think_time 就是一个事务要开始时思考的时间;比如 你要点击一个 登录按钮 我们都要点击这个按钮要先思考下 就是人为脑袋思维的延迟,还有手指点击鼠标的这个动作的时间 一般是1-5秒,这就是思考时间,性能测试模拟思考时间就是模拟真实人为动作的方式来做压力测试.一般在脚本中思考时间是这样写比较合理,在一个事务的结束点另一个事务的起始点,两者中间定义思考时间.lr_end_transaction("登录",

语法分析之自定向下语法分析概述与三个重要概念的集合

 语法分析之自顶向下语法分析概述与三个重要概念的集合   自顶向下语法分析概述:      基本思想 检查程序是否为文法的句子 按定义从开始符号出发能推导出程序 一个一个尝试,选择规则没有依据. 例子:      Z→aBb[1]|aD[2]      B→b[3]|bB[4]      D→d[5]|bD[6] 分析一个串abbd,穷举过程如下 Z#                    abbd# aBb#                  abbd# (a匹配) Bb#        

LoadRunner 技巧之 思考时间设置

用户访问某个网站或软件,一般不会不停地做个各种操作,例如一次查询,用户需要时间查看查询的结果是否是自己想要的.例如一次订单提交,用户需要时间核对自己填写的信息是否正确等. 也就是说用户在做某些操作时,是会有停留时间的,我把这个时间叫思考时间.但利用代码去执行的时候是没有时间的,当然,脚本运行本身是需要时间的,但比起人的思考时间要小很多.这也是我们为什么要用软件来代替人的某些工作. 但有时候,我们在做性能测试时,为了更真实的模拟用户的操作,需要给代码加入思考时间.来看看在loadrunner是如何

loadrunner设置Analysis分析时去掉思考时间

在进行对loadrunner进行执行脚本的情况下,那么就需要在脚本中进行添加为思考时间,这样才更符合人为的脚本时间,那么在进行执行压力的过程中,思考时间是需要开启的,完成之后为了便于分析那么就需要把思考时间去掉,以便更好的分析报告. 在进行生成的报告的界面中,进行点击菜单中"file"的选项菜单.然后就会弹出了下拉菜单中进行选择为"set global filter"的选项. 进入到了global filter的选项界面中,进行选中列表中think time中为位置

微服务分布式事务的一些思考

关于微服务分布式事务的一些思考,笔者没有参与过复杂分布式事务的场景,各位大神路过可以分享一些遇到的案例,大家一起探讨. 关于分布式事务,笔者推荐的处理方法是"尽量避免",如果实在避免不了(这已经是高并发.用户量比较多的网站了)则使用"最终一致性"处理(参照CAP理论base思想),如果处理了事务,但还是遇到了数据错误,那还有最后一道保障,那就是"日志",可以通过日志找回数据,其实大部分互联网公司也都是这么做的.说到"尽量避免"

关联、参数化、思考时间、检查点、事务的设置方式

Action(){ //如果关联的数据过于长,需要在这里将参数存储的值变大web_set_max_html_param_len("1024"); //登陆关联,关联函数就是通过指定的左右边界来获取值的. 如果将加载首页放在vuser_Init或者关联函数前面,执行会报错,//错误 -26377: 找不到所请求参数“userSessionlogin”的匹配项.请检查响应数据中是否存在请求的边界web_reg_save_param_ex("ParamName=Correlatio

loadrunner - 思考时间

lr_think_time(); 等待时间,请求之间的间隔时间:放在事务的外面 ###########作用:1.控制请求发送的频率:2.以达到控制服务器压力的目的########### 思考时间开关:Run-time Setting -> Think Time -> Replay think time 1.As recorder:根据代码设置时间 2.Multiply recorded think time by:代码设置使时间的多少倍 3.Use random percentage of r