关于并发用户数的场景设计问题

zhoward

目前我们所进行的测试都涉及到并发用户数这个概念，一开始我是这么做的
1. 脚本没有设置集合点
2. 场景设计时，采用同时初始化，同时运行，运行5分钟时长，然后同时结束
但是，同时运行所有用户，并不说明所有用户会在同个时刻进行并发动作，毕竟指令的发送有先后，因此改变如下操作方式
1. 脚本设置集合点
2. 场景设计时，采用同时初始化，同时运行，运行5分钟时长，然后同时结束
从上面场景设计，大家可以看出几个设计都存在‘同时’的概念。之前有看过相关的文档，说是并发测试前采用每隔一段时间开始运行用户，结束时再逐渐结束。但是使用这种方法时，却发现用户并未进行所谓的并发。假设测试并发数为100个登录，场景设计时是每隔15s开始运行24个用户，那么实际上是只有24个用户的并发，结束时候也是如此。因此我觉得测试并发用户时，就必须采用‘同时’运行和结束。请大家指正一下。
另外，在测试并发数时，我也是习惯性采用运行一段时间duration的方法，这样多次运行后可以得出比较准确的数据，不知这样操作是否正确。
请指正，谢谢。

mr.bee

可能是你集合点策略中的虚拟用户等待时间的问题
默认等待30秒后面的用户还没到达的话
就不会继续等待未到达集合点的用户直接并发的

“多次运行后可以得出比较准确的数据”
看实际，迭代100000次未必比迭代1次准确哦

夜魅

我猜你没有对集合点策略进行设置，在集合点策略那出了选第二个选项之外，所有的选项皆可以。

msnshow

集合点用得很少，一般的业务不需要集合点

婴儿

并发分2种，时点上的并发和时段内的并发，事实上时段内相同和不同业务的并发更接近实际。
看你的描述，你是要做时点上相同业务的并发。如果设置了集合点，只要集合时间足够长，都能达到最大用户数的并发。
假设测试并发数为100个登录，场景设计时是每隔15s开始运行24个用户，那么实际上是只有24个用户的并发，结束时候也是如此。
这说明在15s内，先运行的24个用户已经通过了集合点。如果不修改运行策略，那么可以修改集合点策略，一般建议这样设置：全部用户到达后才释放集合点，并且用户间超时等待时间够长

zhoward

谢谢各位的回复。之前产生不同用户没有实质并发的情况确实是由集合点策略引起，一直都是使用默认的策略，包括等待时间30s也是，将等待超时时间设长就可以了。有两个问题
1. 对于场景策略的设计，刚听说同时加压或者是逐步加压，这个是对测试机的压力，在相同并发数的前提下，两种策略对服务器的压力实际是一样的。请问这个是否正确？
2. 对于并发测试，习惯用时间点上的测试方法，时间段这种方式，操作并不是在同一个时刻，能形成所谓的把那个发压力么？？

daniel_402

我觉得时间段上的压力不足以说明问题吧，毕竟个虚拟用户并不是同时的操作。
我们现在做的都是时间点上的并发，
但是时间点上并发比如场景一共给了50个虚拟用户，集合点设50个用户在释放，不管按什么规则升压等到50个到了集合点同时释放。这个时候集合点那里又在等待下一组50个用户的到来。但是虚拟用户数一共才50个，肯定时间点的并发之间会间隔一段时间等待50个用户重新聚集在集合点上。这样等待的时间压力就是空的。
我们现在设计比如要测50个时间点并发，会放100个或更多上去，集合点到50个释放，这样集合点就不断地有用户上来，不必要等只有50个。可以实现连续的点的并发

不知道各位认为这样操作有什么问题不？

zhoward

回复 7# daniel_402


你这么做的目的是想‘实现连续的点并发’没错吧，但又没考虑过，你即使是100个虚拟用户50用户的并发，一旦达到50个人数集合点就开始释放，而此时你也无法保证另50个用户也刚好到集合点啊，这样岂不是还有你所谓的等待时间？ 感觉你这样做也是不行的，但问题很新奇，等待答复。

daniel_402

这么就可以增大虚拟用户数，就像50米赛跑一样，跑完得的人不断填充那8个跑道，跑步的人越多，时间段内每8个同时起跑的次数就越多，理论上数量越大就可以达到无限接近上一次，其实实际的的应用也不用这么接近

第八颗北斗星

集合点只是瞬间峰值的压力，可能还不如不设集合点的压力大，因为集合点需要等用户到齐了才能往下执行

zhoward

回复 10# 第八颗北斗星


    我是觉得，虚拟用户只要初始化开始，就对服务器产生了压力，即使是在等待集合点释放时也是照样产生压力。只是在集合点释放时，会产生更大的压力，不知这种理解是否正确？

huyanjun

好贴 顶上去。等待高人出现！

婴儿

性能测试通常不仅仅针对某一个功能，而是要去覆盖大多数业务，最终我们要衡量一个系统的性能，是衡量其在全业务模式下的表现。
假设你要测试10个业务，对应生成了10个脚本，将它们组合成一个场景，不设置集合点，设置持续时间。由于每个脚本的运行时间都不一样，同一脚本每次迭代执行的时间也不一样，每个脚本在运行完成后立即进行下一次迭代，这样，在任一时刻，都有相同或不同业务的自由集合，在任一时刻，都有相同或不同角色在操作系统。个人以为，这样更接近用户实际使用情况，并且频度更大，压力更高。

蚂蚁吞大象

集合点策略对于模拟某些对特定时点业务（比如证劵业务，秒杀等）最有效，一般业务，比如web办公平台，不可能存在某个时点大量业务请求的情形，而会是集中在某个时间段内，这个时候其实是不需要集合点策略的，构造混合场景测试会更接近真实情况。

shwesh

本人刚刚接触LR,  有点疑惑。
比如：脚本中添加了集合点，集合策略选择“运行线程达到 100%释放”，但在观察时发现，多数情况都没有等到100%到达就会有释放的情况。不知大家有没有发行这种情况。

布阿泽雨

回复 11# zhoward

我觉得 只有在Vuser 向服务器提交请求时 才会产生压力

服务器不会主动和某个客户机建立连接  只是被动的响应请求 所以只有请求时才会产生真正的压力