LoadRunner之并发用户数与迭代关系
Loadrunner名词解释
1Loadrunner名词解释响应时间:应用系统发出请求开始到收到服务器所有响应所耗费的时间;并发用户量: 同一时刻与服务器交互的所有用户数量;在线用户数：即同时在使用应用系统的用户，可能在浏览，可能在做交易。
并发用户怎么计算:●一般并发用户数取在线用户的10%-30%。
●八二原则：一般可以认为80%的用户在20%的时间内完成工作，所以峰值压力的时候，一般并发数要乘以80%/20%=4●Loadrunner里计算公式（1）计算平均的并发用户数：C = nL/T（2）并发用户数峰值：C’ ≈ C+3根号C公式（1）中，C是平均的并发用户数；n是login session的数量；L是login session 的平均长度；T指考察的时间段长度。
公式（2）则给出了并发用户数峰值的计算方式中，其中，C’指并发用户数的峰值，C就是公式（1）中得到的平均的并发用户数。
该公式的得出是假设用户的login session产生符合泊松分布而估算得到的。
事务响应时间:处理一个事物花费的时间，包含网络传输时间和服务器处理事务的时间TPS: 每秒处理事务数量资源利用率: Cpu、内存、磁盘io、网络的使用情况;思考时间: 用户进行操作时,每个请求之间的时间间隔2性能测试包含了哪些软件负载测试：通过对被测系统不断加压，直到超过预定的指标或者部分资源达到了饱和不能再加压为止，就像举重的过程中不断加杠铃的重量，知道运动员不能举起。
压力测试：给系统增加一定的压力，在一定的压力下测试的cpu、内存、磁盘、网络使用情况，也即业务能否正常使用；并发测试：通过模拟用户并发访问，测试系统是否存在死锁、系统处理速度是否下降的比较厉害等问题；可靠性测试：在一定的业务压力下，让系统运行一段较长的时间，看系统能否无故障运行；3简述使用软件测试工具Loadrunner的步骤制定性能测试计划—>开发测试脚本—>设计测试场景—>执行测试场景—>监控测试场景—>分析测试结果4什么时候可以开始执行性能测试功能测试通过；一般需要进行性能测试的系统，都是用户量比较大、业务使用比较频繁、比较重要的功能模块。
系统吞吐量（TPS）、用户并发量、性能测试概念和公式
系统吞吐量（TPS）、⽤户并发量、性能测试概念和公式⼀．系统吞度量要素：⼀个系统的吞度量（承压能⼒）与request对CPU的消耗、外部接⼝、IO等等紧密关联。
单个reqeust 对CPU消耗越⾼，外部系统接⼝、IO影响速度越慢，系统吞吐能⼒越低，反之越⾼。
系统吞吐量⼏个重要参数：QPS（TPS）、并发数、响应时间QPS（TPS）：每秒钟request/事务数量并发数：系统同时处理的request/事务数响应时间：⼀般取平均响应时间（很多⼈经常会把并发数和TPS理解混淆）理解了上⾯三个要素的意义之后，就能推算出它们之间的关系：QPS（TPS）= 并发数/平均响应时间⼀个系统吞吐量通常由QPS（TPS）、并发数两个因素决定，每套系统这两个值都有⼀个相对极限值，在应⽤场景访问压⼒下，只要某⼀项达到系统最⾼值，系统的吞吐量就上不去了，如果压⼒继续增⼤，系统的吞吐量反⽽会下降，原因是系统超负荷⼯作，上下⽂切换、内存等等其它消耗导致系统性能下降。
决定系统响应时间要素我们做项⽬要排计划，可以多⼈同时并发做多项任务，也可以⼀个⼈或者多个⼈串⾏⼯作，始终会有⼀条关键路径，这条路径就是项⽬的⼯期。
系统⼀次调⽤的响应时间跟项⽬计划⼀样，也有⼀条关键路径，这个关键路径是就是系统影响时间；关键路径是有CPU运算、IO、外部系统响应等等组成。
⼆．系统吞吐量评估：我们在做系统设计的时候就需要考虑CPU运算、IO、外部系统响应因素造成的影响以及对系统性能的初步预估。
⽽通常境况下，我们⾯对需求，我们评估出来的出来QPS、并发数之外，还有另外⼀个维度：⽇PV。
通过观察系统的访问⽇志发现，在⽤户量很⼤的情况下，各个时间周期内的同⼀时间段的访问流量⼏乎⼀样。
⽐如⼯作⽇的每天早上。
只要能拿到⽇流量图和QPS我们就可以推算⽇流量。
通常的技术⽅法：1. 找出系统的最⾼TPS和⽇PV，这两个要素有相对⽐较稳定的关系（除了放假、季节性因素影响之外）2. 通过压⼒测试或者经验预估，得出最⾼TPS，然后跟进1的关系，计算出系统最⾼的⽇吞吐量。
LoadRunner常见测试结果分析（转）
LoadRunner常见测试结果分析（转）
在测试过程中，可能会出现以下常见的几种测试情况：
一、当事务响应时间的曲线开始由缓慢上升，然后处于平衡，最后慢慢下降这种情形表明：
* 从事务响应时间曲线图持续上升表明系统的处理能力在下降，事务的响应时间变长；
* 持续平衡表明并发用户数达到一定数量，在多也可能接受不了，再有请求数，就等待；
* 当事务的响应时间在下降，表明并发用户的数量在慢慢减少，事务的请求数也在减少。
如果系统没有这种下降机制，响应时间越来越长，直到系统瘫痪。
从以上的结果分析可发现是由以下的原因引起：
1. 程序中用户数连接未做限制，导致请求数不断上升，响应时间不断变长；
2. 内存泄露；
二、CPU的使用率不断上升，内存的使用率也是不断上升，其他一切都很正常；
表明系统中可能产生资源争用情况；
引起原因：
开发人员注意资源调配问题。
三、所有的事务响应时间、cpu等都很正常，业务出现失败情况；
引起原因：
数据库可能被锁，就是说，你在操作一张表或一条记录，别人就不能使用，即数据存在互斥性；
当数据量大时，就会出现数据错乱情况。
loadrunner中各性能指标解释
Transactions（用户事务分析）用户事务分析是站在用户角度进行的基础性能分析。
1、Transation Sunmmary（事务综述）对事务进行综合分析是性能分析的第一步，通过分析测试时间内用户事务的成功与失败情况，可以直接判断出系统是否运行正常。
2、Average Transaciton Response Time（事务平均响应时间）“事务平均响应时间”显示的是测试场景运行期间的每一秒内事务执行所用的平均时间，通过它可以分析测试场景运行期间应用系统的性能走向。
例：随着测试时间的变化，系统处理事务的速度开始逐渐变慢，这说明应用系统随着投产时间的变化，整体性能将会有下降的趋势。
3、Transactions per Second（每秒通过事务数/TPS）“每秒通过事务数/TPS”显示在场景运行的每一秒钟，每个事务通过、失败以及停止的数量，使考查系统性能的一个重要参数。
通过它可以确定系统在任何给定时刻的时间事务负载。
分析TPS主要是看曲线的性能走向。
将它与平均事务响应时间进行对比，可以分析事务数目对执行时间的影响。
例：当压力加大时，点击率/TPS曲线如果变化缓慢或者有平坦的趋势，很有可能是服务器开始出现瓶颈。
4、Total Transactions per Second（每秒通过事务总数）“每秒通过事务总数”显示在场景运行时，在每一秒内通过的事务总数、失败的事务总署以及停止的事务总数。
5、Transaction Performance Sunmmary（事务性能摘要）“事务性能摘要”显示方案中所有事务的最小、最大和平均执行时间，可以直接判断响应时间是否符合用户的要求。
重点关注事务的平均和最大执行时间，如果其范围不在用户可以接受的时间范围内，需要进行原因分析。
6、Transaction Response Time Under Load（事务响应时间与负载）“事务响应时间与负载”是“正在运行的虚拟用户”图和“平均响应事务时间”图的组合，通过它可以看出在任一时间点事务响应时间与用户数目的关系，从而掌握系统在用户并发方面的性能数据，为扩展用户系统提供参考。
LoadRunner使用总结报告
在打开的Launcher窗口中，选择Create/Edit Scripts菜单，打开虚拟用户脚本生成器。
打开协议 新建协议 通过模板新 建协议
快捷工具栏
协议顾问
最近使用的协议
最近使用的脚本
打开新建脚本窗口，选择协议，并创建新的脚本。
从本地硬盘打开已保存的脚本。
根据已有脚本模板创建新的脚本。
打开录制窗口，录制用户操作，系统会自动判断使用使用的协 议，有可能有多个协议，但系统建议的协议并不一定是最优协 议。
LoadRunner包含以下组件： Virtual User Generator：虚拟用户生成器。录制最终用户业务流程并创建自动 化性能测试脚本，即Vuser脚本。
Controller：组织、驱动、管理并监控负载测试。
Load Generator：通过运行Vuser产生负载。负载生成器可以在别的计算机上安 装，然后在测试机通过Controller连接。 Analysis：用于查看、剖析和比较性能结果。 Launcher：使用户可以从单个访问点访问所有LoadRunner组件。
Comment：注释。为代码或者方法、类添加注释。 Log Message：通过LR的日志系统输出日志。
New Parameter：创建参数化新参数。
Toggle Breakpoint：设置当前行为断点，当在脚本编辑窗口，通 过运行命令，程序执行到当前行时挂起，和eclipse的breakpoint 是一样的功能。
如果不设置Pacing时间，即在上次循环结束后，立即进入下次循环，可能会出现因为请求在排队，没有 进入执行状态，而导致的事务相应时间很长，甚至超时。这样得到的最终相应时间，包含了队列等待时 间，会导致结果不准确。 设置Pacing后，会减轻服务器压力，得到的测试结果是服务器非极限状态下的数据。
LoadRunner-迭代和并发设置
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:只取⼀个值(不管并发和迭代是多少)。
LoadRunner中Action的迭代次数的设置和运行场景中设置
LoadRunner中Action的迭代次数的设置和运⾏场景中设置LoadRunner中Action的迭代次数的设置和运⾏场景中设置 是怎么重复迭代和怎么增加并发运⾏的呢？ 另外，在参数化时，对于⼀次压⼒中均只能⽤⼀次的资源应该怎么参数化呢？就是说这些资源⽤了⼀次就不能在⽤了的。
－－参数化时,在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也是可以的。
探讨LoadRunner的并发用户和集合点
探讨LoadRunner的并发用户和集合点近来跟踪一个项目，发现同事们在执行性能测试时，比较热衷于使用集合点，从概念上认为要得到并发用户就必须设置集合点，认为在执行一个压力测试脚本时，设置了集合点才算是有效的并发用户，没有设置结合点，就认为可能这个就不能准确的代表并发用户数。
当前我并反对这个观点，不过却让我有一种疑虑，促使我想更深入的理解并发用户和集合点，我相信大多数进入性能测试研究领域的朋友都应该有疑惑，主要原因我觉得还是由于不能深入理解LoadRunner的实现原理，而且缺乏对系统整个过程的分析，其中这里面涉及到的知识包括网络、协议、中间件、数据库、应用层以及缓冲区和缓存等等，当然还与硬件资源CPU队列和内存等有着千丝万缕的联系。
所以说要成为一个优秀的性能测试人员，真还不一个容易的过程，是需要长时间积累和学习的，只有通过大量的项目实践和分析，最后再总结于思想，才有可能成为这个领域的专家，当然也希望真正想把性能测试做好的朋友都能为此将不懈努力，乐于分享和讨论。
先来看一个应用系统的结构图，如下所示：这个图源于小布老师的视频中，比较直观、简洁地反映了一个应用系统的运行过程，其中包括客户端、网络、应用服务器和数据库服务器，其中每一个环节都是在执行性能测试分析中必不可少的元素，结构图中也合理得分析出了响应时间的处理过程，当请求从客户端发出之后到最后返回到客户端，这个过程中每一个环节的处理都有可能最后成为系统运行中的性能瓶颈，所以可见对系统整体结构的理解是何等重要。
接下来我们来看看关于并发用户和集合点的定义：并发用户：通俗意义上讲就是同时操作的用户，当然这个“同时”可以理解为同一时间段，还可以理解为同一时间点，当然如果说并发就是同一时间点上同时操作的用户，这样理解没有错误，但对于实际情况来讲，是没有严格意义上的并发执行的，就如同进程和线程关系一样，在某一个点严格上讲就只有一个人得到执行的权利。
集合点：用以同步虚拟用户，以便恰好在同一时刻执行任务。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
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的。