|
发表于 2014-12-18 20:42:31
|
显示全部楼层
@maweihuizi 您好!
我大概理解你的意思了, 是不是想多用户共享一个递增数? 比如:
用户1(第一次迭代) -> 1; 用户1(第二次迭代)-> 6;
用户2(第一次迭代) -> 2; 用户2(第二次迭代)-> 7;
用户3(第一次迭代) -> 3; 用户3(第二次迭代)-> 8;
用户4(第一次迭代) -> 4; 用户4(第二次迭代)-> 9;
用户5(第一次迭代) -> 5; 用户5(第二次迭代)-> 10;
....
--------------------------------------------
如果我理解的对,那么接着往下看:
先讲一下 并发原理, LoadRunner 并发机制是 每一个用户,模拟一个线程(5个用户就是5个线程)或进程,他们彼此之间没有任何联系。- 无法进行交互式识别此数字已经被使用,然后去选用别的数字。如果做到智能识别,那么就会涉及一些,因等待其它进程处理而影响压力发送时间片等等一些问题。
- LR场景在执行是进行预编译,也就是说 根据已设定的并发用户数建立线程或进程,把每个用户需要的参数化都进行预编译,进程或线程之间彼此独立,无法进行相互通信,也不知道其它用户执行到哪里了。因为预编译了才可以高速循环发送压力,这个也是和LR回放脚本编译模式不同的地方。
- 文件锁,参数无法共享的另一个原因就是文件锁了,这也是场景结果为什么每次都生成和并发用户数相同数量的日志文件,如果几个用户同时在一个文件里面进行读写,会出错,也会遇到文件锁,那么,创建一个文件,每个用户都时时去同一个文件中读数字,然后改写+1的方法也不合适。(所以压根没给你推荐这个土办法)
这个如果你能理解了,就会考虑这样做是否和我们的并发思路相互违背。
-------------------------------------------
上面的话理解了,那么知道了利弊,我们换个思路,可不可以绕过这个大坑? 答案是可以!
提供两种思路解决该问题或者可以结合使用:
- LR参数化中提供了一种自动生成参数模式:<Unique Number> 即多用户共享自动递增,并且所有用户都是不重复的数字! 是不是感觉这个参数和我上面说的相矛盾?其实不然,Mercury 是一个 NB 的公司,这些问题早已经考虑到了。 它给出的策略是 分块 ,什么是分块,就比如你要 5用户并发, 共享25个数字。 那么在LR场景运行前编译中,就把这25个数字参数按块的方式每个用户分了一块(例如用户1->1,2,3,4,5; 用户2->6,7,8,9,10;)
用户1(第一次迭代) -> 1; 用户1(第二次迭代)-> 2; 3; 4; 5;
用户2(第一次迭代) -> 6; 用户2(第二次迭代)-> 7; 8; 9; 10;
用户3(第一次迭代) -> 11; 用户3(第二次迭代)-> 12; 13; 14; 15;
用户4(第一次迭代) -> 16; 用户4(第二次迭代)-> 17; 18; 19; 20;
用户5(第一次迭代) -> 21; 用户5(第二次迭代)-> 22; 23; 24; 25
注意: 和上面的顺序不同。
这样就解决了 5个用户每个用户执行5次,每次参数都不同,但是都在范围之内。
上面的策略是:
- 使用参数 <Unique Number>
- 设置 Start = 1;(从1开始,每次递增1)
- Block = 5;(每个块里面5个参数)
- Updata value = Each iteration;(每次Action循环变参)
- When out of Values = about Vuser; (参数用完自动宕掉Vuser)
把数字设置的大一些,就可以规避 down vuser 的问题了。
2. 如果上面的方法可以完全解决你的问题,那么最好不过了, 如果数据库中必须按照顺序递增,(也就是 VU1必须对1,VU2,必须对应2),不可以跳跃递增,那么考虑用 参数取模计算的方法去做. . 这样可以合理的让VUSER1执行 -> 1,5,10,15,20,25. vuser2-> 2,6,12,16....
3. 把5只交易整合成一个脚本, 5个Action , 脚本执行时是按照顺序执行Action 1-5 的。
希望能帮到你
|
|