并发设置，对脚本进行设置和场景里设置，有区别吗？
一、并发搜索：要对网站进行搜索，用户是不需要登陆就可以进行搜索的，达到100个游客的并发搜索，得到的结果列表页的平均响应时间。1、录制脚本，对搜索条件的参数化（100），在场景设置中，分五个组，每个组Vuser20个，并设置集合点，并发。这样能达到100次搜索同时进行吗？
2、录制脚本，不进行任何修改，在场景中，设置组Vuser100个，运行。这样能达到100次搜索同时进行吗？
3、录制脚本，插入集合点，然后在场景中，设置组Vuser100个，运行。这样能达到100次搜索同时进行吗？
4、录制脚本，不进行任何修改，在场景中，分十个组，每个组Vuser10个，并设置集合点，并发。这样能达到100次搜索同时进行吗？
5、录制脚本，对搜索条件的参数化（100），在场景中，设置组Vuser100个，运行。这样能达到100次搜索同时进行吗？
上面五种情况，哪几种可以达到我要的的并发呢？每种之间有什么区别呢？
上面五种我都试过，得到的事务的响应时间是呈向上趋势的一条曲线，而我在资料上看到的是：该曲线应接近于平行X轴的一条直线。
那我测试结果的这个事务响应反应的是什么情况呢？请指教！~~~
事务响应时间图，如下：
[ 本帖最后由 zlpxm 于 2008-5-23 11:30 编辑 ] 看你的看混了
还是说我自己的好了，如果是我，我会这样
录制开始
init部分：
1.打开搜索页面
action部分
1.插入集合点
2.输入搜索条件（后期参数化）
3.插入事务起点
4.点击搜索
5.插入事务终点
录制结束
然后设置好迭代等等```:lol 我的理解：
init部分：
1.打开搜索页面
action部分
2.输入搜索条件（后期参数化）
1.插入集合点
3.插入事务起点
4.点击搜索
5.插入事务终点
录制结束 那并发的数量在哪里设置呢？就是参数化，场景里不用设置吗？ 支持shen1936
我也像shen1936那样做的
可以设100个不同的参数，也可以就设一个，设置迭代，个人认为是这样:)我的做法
脚本：像shen1936那样录制，然后在脚本中对搜索条件进行参数化场景：设置100个用户并发，同时设置迭代次数，或者运行一定时间
shen 1936才是我想说的
不好意思，我把集合点的位置写错了shen1936的才是我想说的 谢谢大家的回答
我按照shen1936的方法录制了脚本，参数化了91个，在场景里也设置了91个并发
通过了
这是用户的事务响应时间表，不知道怎么看？能否指教一二？
[ 本帖最后由 zlpxm 于 2008-5-26 10:05 编辑 ]
回复 9# 的帖子
你这里的a，就是搜索的事务吧？如果这条向上走的线是在加压过程中的线，是正常的，如果是在迭代或是持续时间内，也是向上走，说明你的系统有问题 哟，建议和user图合并起来一起看。还有就是你的响应时间里面有没有思考时间，如果不包括思考时间，90％的事务思考时间都为36.572，也有点偏大回复 10# 的帖子
a是搜索的事务，我是参数化后加压的，不是进行迭代的。因为我个人以为迭代是一个接着一个进行提交数据，不能认为是完全的并发。我的响应时间里是没有思考时间的，我并发了91个搜索，这个数据还是偏大吗？那造成这个数据偏大的原因是哪些呢？
我又重新试过了一遍，是100个搜索并发的，没有思考时间，依旧是没有迭代的，seach-begin是搜索的事务，seach是集合点。
这图里的数据比9#的图里的数据更大，而且action的直线在事务之上了，这个正常吗？
[ 本帖最后由 zlpxm 于 2008-5-26 18:06 编辑 ] 没人耶 我很好奇你的系统，为什么要做100个查询的并发，搜索引擎？
要知道即便你设置了并发，实际上100个用户也几乎不可能是同时并发的，因为网络的延迟和LR自身设置等原因，会有一部分VUSER先释放出来的
首先你应该确定是否需要100个用户的并发，然后再做测试场景
如果真的需要100个用户的并发，你这个值确实比较大，你可以从界面上手工计算一下响应时间，然后再看
页:
[1]
