持续时间的意义

持续时间的意义
说法一：
就是你的压力持续时间,可能rump up的速度非常快,这个时候如果没有持续时间,很快脚本执行完成,就结束了,测试的目的就达不到了,如果设置了持续时间,脚本就是反复执行,这样保证了SUT压力的持续.
另外,还有的时候,脚本很短,你rump的时间非常慢,后面的VU还没有启动,前面的VU就结束了,就达不到你的要求了,可以通过设置集合点或者增加持续时间,快速rump up来避免
说法二：
思考时间个人认为并不是字面上的意思，只是系统在此停滞了多久，假如设置思考时间10s那么系统就在此停滞10s，用户在某一操作时不可避免的有停止该项操作xx时间的行为。

设置思考时间就是让脚本中的各函数的运行有个停滞时间,可以更真实的模拟用户操作的真实情况.就好比你浏览一个网站的时候,你的操作步骤之间都会有一定的时间间隔的，主要都是更好的模拟实际情况，但是有时候也可用于“减压”。

如果不设置思考时间，测试的压力就更大！
说法三：
12楼：
思考时间就是停留时间
就像你点击1个网页,要等等图片才出来你再点击别的
去掉思考时间,就是你点了后不等图片马上再继续点别的
2者之间就产生了很大的区别
先前有时间等待的你提交1次服务器就给你发1次发完服务器就休息了
但是你一直在发服务器就一直不休息压力就大很多了
不知道这样比喻你懂了没呵呵
12楼有点误导人了，点击频率越大对服务器的压力更大
设置了思考时间就是等系统结束一个事务的时候停留一段时间再执行下个事务吧
这样一个是可以更真实的模拟现实情况
还可以减少服务器的压力
说法四：
当“运行[时间]在加压完成后”设置了以后，原本定义的运行时设置中的迭代次数就失效了。

或者说加压“持续时间”的优先级要高于“运行时设置”。

比如当一个脚本设置了运行时设置中的迭代次数为10 次，在“持续时间”中设置加压持续时间为30分钟。

当真正运行时，脚本迭代10 次后仅花费了20分钟，但是持续时间设了30 分钟，因此它不能停下来，还会继续迭代。

到最后脚本实际迭代的次数就不止10次了。

说法五：
A：lr中设置场景时加载方案中的“持续时间” 运行多长时间怎么理解。

持续时间设置将覆盖Vuser 迭代设置。

这意味着，如果将持续时间设为五分钟，那么Vuser 将继续在五分钟时间内运行尽可能多的迭代，即使运行时设置仅指定一次迭代。

这是操作手册中的解释，不是很理解。

是不是意味着同时并发的时候运行的用户数不止我设置的那么多人数
B：持续时间，是指达到集合点后，所有虚拟用户运行的时间
C：数据库评估效果怎么做？主要注意哪些方面的地方
A：那么虚拟的用户〉我设置的用户数，是不是这个意思
B：我这里没有针对数据库来做性能调优，是因为发现事务响应时间过慢，所以调整数据库。

评估是根据响应时间来的
C：有哪些指标可以用？
B：就好像跑步，迭代＝跑几圈，持续时间＝跑10分钟，这里和虚拟用户没关系，无论是2个人、或者是100个人跑
A：很形象的比喻我大概理解了。

那么这个设置“持续时间”的长短跟要测试的整个性能有什么影响了。

设置持续时间的长短有没有关系
B：我个人理解：关系不太大了. 只要运行个若干次就差不多了
D：时间的长短肯定跟性能有着很大的关系的。

时间的长短也跟你测试的方式有关。

例如负载测试，是从小到大的测。

一般的性能测试只是模拟用户真实的操作环境，真实操作时间，过程。

A：假如说测试登录你会怎样设计方案
D：测试登录的方案，首先，你必须考虑你的用户群大体有多少人，高峰期的时候存在着多少人登录，而一般性况下同时有多少人在线。

考虑高峰时期的登录人数再设置并发数。

A：假设高峰期有15个用户同时登录
D：高峰期是你设置运行人数的最大值。

并发就是通过高峰期来设置的。

A：就是设置集合点时启用禁用多少用户？
E：那运行的时候数据是否写入真实的数据库里去的呢?
D：关于并发时启用多少用户，是看多少用户时登录系统最大并发的可能性是多少来设置的。

是否写入真实数据库。

这个不知道你说什么
E：这么多用户执行脚本时,数据不写进去的吗?比如进行注册操作
D：肯定要写入数据库中的
E：那行进迭代的话,不是要写入相同的数据了吗?
D：如果是压力测试的话，你就尽可能地让数据库多增加数据。

然后再取出来
E：如果用户不能同名,迭代是否没有意义了呢?
D：写入相同的数据，那就是你的的代码编辑方面的问题啦
E：我说的是迭代的情况
D：这个很好处理
E：你就尽可能地让数据库多增加数据。

然后再取出来,怎么取出来? 怎么处理？就是比如10个用户的,迭代二次,我加个20条数据就行了,是吗?
D：int s=rand(); 用随机数来处理
E：这个是在脚本里就先设置好的吗?
D：对的，你如果你的系统对于用户注册名不能重复的话。

你可以自己写代码处理，方法有很多
E：如果是压力测试的话，你就尽可能地让数据库多增加数据。

然后再取出来，怎么取的呢?
D：呵呵，这个我没有讲清楚。

就是例如查询。

或例如用户页面打开。

打开时他的数据就会取出来。

E：哦,原来是这个意思啊
D：负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。

压力测试是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。

F：一般负载测试有没有什么加压标准？如日常压力的2～3倍？
D：这个好像没有听说过标准。

这个一般测试时是根据你系统的承受能力来加压
F：一般负载是逐渐加载压力上去的，加到什么程度可以退出？有没有约定？
在跑场景中有个持续时间（duration）
如果我一个场景可能在2分钟内运行完成（比如订票）
那我持续时间设置为5分钟的时候，是不是这个场景会运行2次半？
本来是定一张票的，变为了顶2张票？
guanrui0309
2010-4-01 18:04:50
你可以看一下CONTROLLER的手册，如何介绍这个参数的。

duration如果设置成5分钟，就是你这个场景要执行5分钟，具体几张票那就不知道了。

union_life
2010-4-02 09:54:36
在持续时间内如果运行完毕，就会迭代执行，直到时间结束，能运行几遍就会运行几遍，即定到几张票，除非中间出现错误或者异常退出
gucciyoung
2010-4-02 15:06:24
恩谢谢ls两位，那我想的就没问题了
不过如果我想和实际的场景一致呢，这个时间如何设定？比如并发200个用户订票，每个用户顶一张票，那我怎么知道订票流程的时间是多少呢？从而制定出合理的持续时间？
siusinxy
2010-4-02 16:30:45
如果你只想让场景跑一次，那就不用设置持续时间了，直接运行，迭代1次就行，LR会根据每个用户的响应时间，给个平均响应时间出来的；
Book
2010-4-02 16:48:59
会迭代执行的，可以通过调整thinktime调整时间
llxue
2010-4-13 10:11:05
嗯，不用设置时间，就是跑一次，跑完就停止
jswyj
2010-5-18 15:01:21
如果强调需要200同时并发是不是考虑下集合点的设置?
Vuser 迭代设置。

这意味着，如果将持续时间设为五分钟，那么 Vuser 将继续在五分钟时间内运行尽可能多的迭代，即使运行时设置仅指定一次迭代。

请问你说的迭代是什么意思？是说这个Vuser在做完一次对服务器的访问之后，自动做下一次的访问吗？就相当于在脚本中写了循环语句吗？
我发现设置了持续运行时间之后，事务的相应时间变大了好多，那么这个事务时间有意义吗？
跌代就是你的脚本反复运行,相当于循环.
联想起前几天看到的一个帖子,说持续运行怎么在脚本里面些循环,其实就是这个意思,不用循环,在RTS里面设置跌代即可完成这一操作.
持续进行压力,如果服务器的性能不好,当然会有事务的响应时间的变长,这没有什么问题,有意义.
你设定了时间,
将继续在设定的时间内运行尽可能多的迭代。