LoadRunner之并发用户数与迭代关系---并发数与迭代的区别

Q1:

例如在LR里，我要测100个用户同时并发登陆所用时间，那我是不是在录制好脚本后，需要参数化“用户名”，“密码”以及在那个记事本里构造100个真实的用户名和密码？ 然后运行Controller，设置用户数为100？

A: 恩，你说的是对的。但是我需要说明的是测并发数的时候，本身就是模拟的虚拟用户，所以我认为不一定非要参数化100个用户，用一个用户跑100遍也是可以的。当然你这样进行设置的话更符合实际情况。

Q2:那么这里的迭代次数该怎么设啊，设成1和设成10有什么区别啊？我老是搞不清测试并发用户，“迭代”和“并发用户数”（就是controller里设的虚拟用户数）的区别。

A: 迭代次数如果你设置为1，那么你的脚本就只跑100遍（续Q1）,如果你设置为100，那么当你设置并发数为100，那么脚本就要跑100*100=10000 遍。懂了吧，当然我说的这种情况是在你没有设置Conrtoller中的durantion，如果你设置了这个场景的持续时间，那么你运行的场景时间就以这个时间结束为准，和迭代次数就没有关系了。

Q3:还有一个小白问题，就是假如我用LR测100个用户同时注册一个网站的帐号，参数化了100个用户名和密码，那么我跑一遍脚本，并跑通了，并在controller里也run了一遍，那么这100个新增帐号是不是就真在数据库里添加了啊？

A:是的，如果你的脚本没问题的话，那么你的数据库里肯定会有100条记录的。你可以自己查看数据库，或者访问你所录制的脚本网站，都能看到相应的记录。

Q4:对于并发数更多的情况下呢，例如并发书是1000，那是不是应该在多个机器上运行才可以阿？ 
A:不一定啊，如果你有条件的话，当然多台机器运行得出的结果更为准确，但是用LR如果是录制web应用程序的话，最大并发数可以到10000的。、

关于LoadRunner中并发用户和迭代次数的问题

我要测试文件上传支持的最佳并发用户数脚本是ftp+http协议的，如下设置：
=========================
集合点
事务开始：上传文件
ftp连接
ftp上传文件
ftp断开连接
事务结束;上传文件

事务开始:将记录添加到数据库
添加到数据库的代码
事务结束：将记录添加到数据库
==================================

我是这样设置的，在action中参数化了10个用户，迭代次数也是2

问题1：假如我要测试10个并发用户，场景中是否设置5个用户就可以实现10个并发呢？
问题2：在场景中设置20个并发用户的话，我的参数只有10个，运行时会怎样执行呢？
问题3：假如我要模拟不允许同一个用户上传同一个文件2次，是否我的并发人数是多少，就要设置多少参数呢？
那参数化时，是否就是用户是一个文件，
文件的信息:文件名，文件描述，文件类型是一个文件。
然后将用户设置为取值唯一，
如果这样的话，一个用户是否只能上传一个文件了？

麻烦大家了，我是刚开始学的。。。

 

 

问题1：假如:要测试10个并发用户，那么在场景中就要设置10个虚拟用户。脚本迭代设置1
问题2：参数的取值方式，在参数属性中进行设置；
问题3：如果只是不允许同一个用户上传同一个文件2次，而不同的用户可以上传相同的文件，则只需将用户进行参数化，并设置取值方式为唯一。
如果不同的用户也不允许上传相同的文件，则需要将上传的文件也参数化，并设置取值方式为唯一。

 

 

 

lr参数化——多个用户取同一条数据（500户并发迭代1次 循环取5条数据）问题

lr参数化——500户并发迭代1次 循环取5条数据
lr参数化——500户并发迭代1次 循环取5条数据
比如vuser1、vuser2、vuser3..........,vuser500
shuju1,shuju2,shuju3,shuju4,shuju5
想实现vuser1取shuju1，vuser2取shuju1，vuser3取shuju1，vuser4取shuju1，vuser5取shuju1..........vuser100取shuju1。
vuser101取shuju2，vuser102取shuju2，vuser103取shuju2，vuser104取shuju2，vuser105取shuju2..........vuser200取shuju2
。。。。。。。
vuser401取shuju5，vuser402取shuju5，vuser403取shuju5，vuser404取shuju5，vuser405取shuju5..........vuser500取shuju5
或者
vuser1取shuju1，vuser2取shuju2，vuser3取shuju3，vuser4取shuju4，vuser5取shuju5，
vuser6取shuju1，vuser7取shuju2，vuser8取shuju3，vuser9取shuju4，vuser10取shuju5。。。。。。。
 
 
方法1、造数据，把5条数据中每条都复制成100条，总共500条，唯一就可以了
---------------------

loadrunner中并发数与迭代的区别

 

网友问题： 

例如在LR里，我要测100个用户同时并发登陆所用时间，那我是不是在录制好脚本后，需要参数化“用户名”，“密码”以及在那个记事本里构造100个真实的用户名和密码？ 然后运行Controller，设置用户数为100？那么这里的迭代次数该怎么设啊，设成1和设成10有什么区别啊？我老是搞不清测试并发用户，“迭代”和“并发用户数”（就是controller里设的虚拟用户数）的区别。 

 

 

 

ZEE的回答： 

用比喻的方式来回一下： 

 

四车道的马路，如果只有四辆车并排走过就是并发； 

如果四辆车排成一纵队走过就是迭代； 

如果有100辆车排成25行依次走过就是并发加迭代。 

在以上说法中，只有并排的车是我们设置的用户数。 

 

 

以下内容是转载的，只做记录一下： 

 

通过用lr做负载压力测试过程发现，如果设定不同的action迭代次数，每次得出的结果是不同的，曲线的表现形式也是不同的。这点就使我们会感觉困惑,为什么要设置action的迭代次数？以及对于不同的应用系统应该怎样设置迭代次数呢？ 

 

首先你要理解性能测试是在干什么？ 

 

性能测试是模拟系统一段时间内真实的压力情况，以考察系统的性能。 

 

再看怎么模拟系统真实的压力情况？比如在半个小时内，用户都在进行登录操作，且平均分布在这半个小时内。我们要做的是什么？模拟这半个小时用户的行为。怎么模拟？估算出同时操作的人数，并用LoadRunner不断的发送登录请求，这就是我们为什么要迭代。 

 

至于迭代次数，只要能够模拟出真实情况，多少次都无所谓，不过10次8次估计是模拟不出来。迭代次数至少要保证压力达到一个稳定值后再运行一段时间，这样我们得到的数据才是有效的。所以我们除非是特别要求，一般不用迭代次数，而是用运行时间。 

 

1，迭代和并发，是完全不同的概念。没有什么关系。 

 

比如，一个用户迭代十次，还是一个用户的压力。 

 

10个用户执行一次，就是10个用户的压力。10个用户迭代10次，还是10个用户的压力。但他们都和参数化的数据有关系（也要看参数化是如何设置的，以及系统如何判断提交值的）。 

 

2,你要是想知道，LR是如何实现迭代和并发： 

 

说一个比较容易理解的层面：迭代就是不停的反复调用同一脚本，反复执行，注意，对1个用户执行10次来说，只会分配一块内存。10个用户执行一次，是调用同一脚本10次，会分配10块内存。LR调用脚本，编译后，运行，按脚本发送数据。 

 

比如：web_url这样的函数，执行就会发HTTP request。 

 

如果你还想知道更细节的进程和函数的实现，只能侧面验证（具体方法看各人的能力和擅长），因为我们都不是LR的开发者。 

 

3,太显然的问题了，参数化时选择每次出现唯一，只要参数够用就OK，不够用，就设置相应的规则。 

 

action在场景运行中iteration只对其起作用，对vuser_init和vuser_end都不起作用，action是一个可以被重复使用的最小单位其实你可以将所有脚本录制到一个action里，只是不方便管理罢了。 

 

举个最简单的例子，像lr自带的例子——订票系统，你如果把所有脚本都录制到一个action里，那回放的时候，每个用户登录就只能买一张票，而如果想一个用户买多张票的话，这样就行不通了。那你就要设多个action，并把登录和结束各录制在一个action里，把买票录到一个action中，这样，将买票的action迭代多次，而用户登录和结束只运行一次，这不就模拟了现实中的情况了吗？ 

 

其实LoadRunner 是以客户端的角度来定义“响应时间”的，当客户端请求发出去后， LoadRunner 就开始计算响应时间，一直到它收到服务器端的响应。这个时候问题就产生了：如果此时的服务器端的排队队列已满，服务器资源正处于忙碌的状态，那么该请求会驻留在服务器的线程中，换句话说，这个新产生的请求并不会对服务器端产生真正的负载，但很遗憾的是，该请求的计时器已经启动了，因此我们很容易就可以预见到，这个请求的响应时间会变得很长，甚至可能长到使得该请求由于超时而失败。等到测试结束后，我们查看一下结果，就会发现这样一个很不幸的现象：事务平均响应时间很长，最小响应时间与最大响应时间的差距很大，而这个时候的平均响应时间，其实也就失去了它应有的意义。也就是说，由于客户端发送的请求太快而导致影响了实际的测量结果，设置步长则可以缓解这一情况，这样，应该试试设置pacing，再运行看看情况。

 

 

 

LoadRunner-迭代和并发设置

迭代：指运行一次脚本时某段代码块(action)循环执行的次数，串行执行

并发：指同时运行脚本的次数，并行执行（多个用户同时跑）

以下是用例和对应的相关设置

Iterations是在Vuser Generator的Run-time Setting中进行设置

Quantity是在Controller Scenario中进行设置

其余是在Parameter List 中进行设置

1.select next row：参数值取值的顺序

Sequential（顺序），Random(随机)，Unique（唯一 ）三个选项；如果要求使用不同的账号登录则设置为Unique；

如果构造的账号数不够又对用户是否相同不做要求，则可以设置Sequential，参数调到最后一列后再从第一列开始调用。

2.update value on ： (什么事件)触发参数取值更换

each iteration：进入一个迭代更换一次参数值；（sequential时）每个迭代不同用户使用相同参数值（不管并发是多少）；(unique时)每个迭代不同用户使用不同值

each occurence :脚本中每次变量出现就换一个新值，谨慎用，用于账号肯定不行。（比如user1登录user2权限操作）

once:只取一个值(不管并发和迭代是多少)

controller中多用户并发时候，每个用户使用完参数化中的数据不在重复使用且每个用户不使用相同参数化数据的方法

工作中经常遇到标题中这样的情况，看到群里也经常有人问，操作很简单，如下：

select next row：Unique(唯一)

说明：每个Vuser取的参数都不一致，确保数据唯一性。

Upate value on:Eachinteration(每次迭代)

说明：每次遇到参数都取一个新值，如果在脚本的一次迭代中，该参数出现两次，那么两次都取不同的值。

如图设置，每次每个用户取不同的值，保证每个用户使用的流水号数据唯一

loadrunner中并发数与迭代的区别

录制脚本时只会有1个虚拟用户，1个虚拟用户可以有多次 迭代，也就是 重复执行 Action里面的内容，在场景设置的时候，如果你说的10时在runtime-setting的Run Logic里面设置的，那就是1个虚拟用户 迭代 10次，并且要求你设置的场景Duration的类型为Run until Completion 时，这个设置才会起作用，如果Duration的类型是Run for <时间>， 这个意思就是1个用户在这段时间内不停执行Action里面的操作。

追问：

不是那个意思，我知道迭代，好像在参数化的时候，在table里面要设置几个虚拟用户的用户名和密码，在场景设计的时候有10个，不知道这两个之间的区别，那在录制脚本的时候比如要多用户的登录，在哪里设置用户数？

 

回答

  

用户登录的流程是不是把 用户名和密码提交到服务器，每个用户的用户名不一样吧？所以你录制1个用户的登录，然后把这个用户的操作复制多个，然后把复制的用户名和密码都改成唯一的，是不是就有多个用户了。loadrunner里面的1个虚拟用户就是1个线程（或者进程），然后把每个线程里面的用户名改成不同的，启多个线程，就是多个用户了。你在写脚本的时候就是创建1个源文件（被复制的对象），controller的作用就是复制多个线程，复制的线程的用户名就是从你table里面取出来的。录制脚本就是创建第一个源文件的过程，controller是多个用户并发的时候。你可以先看一下loadrunner的用户手册

 

脚本迭代的意义是假设设置迭代为N次，运行一次脚本，循环会先在init运行一次，然后在action运行N次，最后在end运行一次，然后退出（假设只有一个action情况下）。
那么首先要说，在场景下面无论是一个用户还是多个用户，都是去读脚本，如果没有设集合点，这些用户完全是各自跑各自的，随机地跑完同一脚本。第一个问题如果设置时间很短，虚拟用户也会跑完脚本再停止，也不会报错。
在脚本里面设置参数的时候可以设置变量在迭代方式上怎么取值，也可以设置不同用户都是怎么去取值（用户和用户之间没什么关系）假设是M个用户，脚本迭代N次，那么在跑场景的时候（假设场景设置用户跑完场景就停止），每一个用户都会去跑一遍脚本（一个脚本迭代N次action）；如果场景设置5分钟，则M个用户自己跑自己的，跑够五分钟，然后最后一次脚本跑完，就停止了。

 

并发用户数量，有两种常见的错误观点。一种错误观点是把并发用户数量理解为使用系统的全部用户的数量，理由是这些用户可能同时使用系统；还有一种比较接近正确的观点是把用户在线数量理解为并发用户数量。实际上，在线用户不一定会和其他用户发生并发，例如正在浏览网页的用户，对服务器是没有任何影响的。但是，用户在线数量是统计并发用户数量的主要依据之一。并发主要是针对服务器而言，是否并发的关键是看用户操作是否对服务器产生了影响。 因此，并发用户数量的正确理解为：在同一时刻与服务器进行了交互的在线用户数量。这些用户的最大特征是和服务器产生了交互，这种交互既可以是单向的传输数据，也可以是双向的传送数据。 比如说：有一个这样的场景，系统在线用户是100个，但是同时操作某一个事物（比如说登陆操作）的人是20个那么场景怎么设计了？在Controller中设置100个虚拟用户执行这个脚本，然后登陆操作之前放一个集合点，然后设置集合点的策略（20个用户到达时即执行集合点） 对于多个业务场景, 只要录制多个脚本放在同一个场景内, 然后分配不同比例的虚拟用户就可以了, 如果不想跑哪个业务场景, 那就不选中这个脚本即可.

 

 

 

追问

  并发用户数，我可不可以在采集的时候理解为最大的允许vuser值

 回答

  某个脚本设置的vuser值, 可以理解为这个业务场景的并发用户数,但如果要测试具体某个业务的并发操作,  那就需要设置集合点, 而且集合点数目不能大于vuser值.

 

 

 

 

问题1：LoadRunner是怎么重复迭代和怎么增加并发运行的呢？

 

问题2：另外，在参数化时，对于一次压力测试中均只能用一次的资源应该怎么参数化呢？就是说这些资源用了一次就不能在用了的。

 

　－－参数化时,在select  next row选择unique,update value on选择 each occurence,

 

　1. 迭代跟虚拟用户数没什么必然联系

 

　迭代是这样的：

 

　迭代1次   迭代2次  迭代3次

 

　用户1     X1           X2             X3

 

　用户2     Y1           X2             Y3

 

　其中的X1-3 Y1-3是参数，参数规则就是二楼说的

 

　这么两个用户是根据你的rump up 上来的，比如5秒上两个用户，那么用户1和2就在5秒之内加载进来的，不知道说清楚了没。

 

　第二个问题就简单了，只能用一次的参数，首先确保你的参数足够，另外规则选择的时候，注意选择唯一

 

　迭代次数只是对你设置了迭代次数的action进行迭代，而用户数可以理解为对整个录制过程的迭代（只是各个用户不同）　而且增加并发量可以通过增加用户来达到　还可以设置集合点来增加某个操作的并发量

 

　假如一个脚本，设置最大并发量为10，每5秒中增加2个并发用户，而Action设置的迭代为10次：

 

　当开始至2秒时，加载了2个用户，这2个用户分别开始运行，并都运行10次，不管这个2个用户运行10次是否结束，当下一个2两秒到来时，即开始至第4秒时又加载了2个用户，这2个又运行10次；就这样一直加载到10个并发用户，然后当每个用户都运行完10次时就结束。

 

　这样中间最大并发是10个，但不一定能达到10个，因为在加载最后几个时，前面的有可能已经运行结束，所以如果要真正达到最大并发10就必须设置集合点来完成

 

　不过也不一定非要设置集合点才能实现同时处在running的状态有10个用户。

 

　设置duration也是可以的。不过那就不只每个用户运行10次了。

 

　如果想实现用户迭代10次，并且想同时running为10个用户，就应该设置集合点。

 

　迭代（Iterate）设计，或者我们称之为增量（Incremental）设计的思想和XP提倡的Evolutionary Design有异曲同工之妙。