集合点？ab？
集合点，按我的理解是当设置集合点后，controller将达到用户设置的并发数后才发送请求，对于先完成的请求将等待后完成的请求，直到再次达到用户设置并发数。然而问题来了，当用户数设置的并发数为1时，如果按以上理论，将不存在集合等待的时间，那么应该类似于无并发的请求，但是结果并不是想象中的那样。
在对于一个静态下面的测试中，1个用户的并发链接，平均每秒处理数为2.922.平均响应时间为0.001，而不设并发1个用户的链接，平均每秒处理为783.236，平均响应时间为0.001
此外不知道有人用loadrunner和apache自带ab比较过没
比方说
ab -n 10000 -c 10 http://.........
这是否等于loadrunner中的10并发，10000此迭代？
结果也是千差万别 不要沉了
大虾解释下吧 ab我没有用过.
集合点如何工作取决于你的策略配置。
如果都是按默认的，应该是对所有运行状态的用户生效。而集合点设置为１个用户的话，我没有做过这个实验。
不过这个肯定和不设置集合点有差别。
有时间做个实验再来看看这个问题。 谢谢zee
1个用户的并发我做出来的是自定义的事务平均响应时间为0.001，然而Action_Transaction的平均响应时间却占用了0.3多
这样我就得出一个结论
如若在并发的情况下由于Action_Transaction会消耗了一定比例的时间，这样用户所关心的平均每秒处理数将失去意义，因为这并不准确，其实只要关心自定义的事务平均响应时间就好，看是否能达到需求，然后找到这个最佳并发数和最大并发数。
反之，在不设并发的状态下，由于很少用户不需等待时间不断的发送请求，服务器资源很容易就被占满，这时关注的重点才应该是程序服务器最大每秒处理数
不知是否正确，感觉自己貌似在进入个死胡同，但是有没有好的理由说服自己出来，望高人指点
另外请研究过ab的同学说说不同之处吧 你在设置了集合点之后，你自定义的事务的平均响应时间，和没有集合点时有什么大的区别？ 这个没有区别，只是在设并发的状态下Action_Transaction平均响应时间变得很大 如果子事务并没有太多的区别的话。
讨论一下你的问题。
１，“如若在并发的情况下由于Action_Transaction会消耗了一定比例的时间，这样用户所关心的平均每秒处理数将失去意义”。
这里并不会失去意义，因为一般说来，我们设置子事务就是为了得到我们关注的函数段的处理速度，而action做为一个默认的事务。很多情况下，都不会成为我们所要的数据标准。也就是不会成为每秒事务数这个指标。
从而后面你说的，自定义的事务，才是关注的要点。
２，“反之，在不设并发的状态下，由于很少用户不需等待时间不断的发送请求，服务器资源很容易就被占满，这时关注的重点才应该是程序服务器最大每秒处理数”
不知道你说的容易占满是什么意思？在没有集合点的时候（就是你说的不设并发的意思吧）压力相对来说比较平均。这里服务器相对比较轻松才是。 这个也许我没有说清楚
简单的说
我认为：
设置并发，关注的是响应时间，每秒处理数不重要
不设并发，关注的是每秒处理数，响应时间相对来说不太重要 哈哈，可以这样理解。 万分感谢:lol :kiss: 万分感谢:kiss: 原帖由 kasimxiao 于 2008-9-1 15:36 发表 http://bbs.51testing.com/images/common/back.gif
这个没有区别，只是在设并发的状态下Action_Transaction平均响应时间变得很大
设置了集合点，Action_Transaction里包括了集合点等待的时间。
页:
[1]
