并发基础概念
并发性能测试的过程，是一个负载测试和压力测试的过程。即逐步增加并发用户数负载，直到系统的瓶颈或者不能接收的性能点，通过综合分析交易执行指标、资源监控等来确定系统并发性能的过程。并发性能测试是负载压力测试中的重要内容。从一个完整解决方案的角度考虑，并发性能测试概括为以下3类：
应用在客户端性能的测试；
应用在网络上性能的测试；
应用在服务器上性能的测试。
这个是网上找到的比较笼统的概念
个人理解： 并发 是 每个用户 在当 秒钟 发出的请求10个是否可以说 这个用户 并发是10呢？
我觉得 还存在一个时间差的问题 1 个用户 发出每秒发 10 请求和 10个用户 每秒发出1 个请求时有区别的 大家知道的
现在一个用户 一个请求发出 和 1个 用户 同时发出10 个请求 也是应该有区别的个人觉得
例如：LR 我设置思考时间为0 100个用户 1秒了服务器TPS = 1000 服务器这秒内处理 1000个请求那么我可以说 这秒 并发就1000吗？？
因为 用户行为是请求完成 再次请求的 UPUP 顶 我觉得1个用户同时发出10个请求和10个用户同时发出一个请求相比较而言，10个用户同时发出一个请求更能模拟现实情况。
至于时间差问题，受环境限制，肯定会有的，但是现实中也会有时间差吧。 看楼主写的之后比较晕。。
并发从性能测试的角度上来讲，应该是在同一时刻，向某个应用、某个入口或某个数据表发送多条操作，来验证是否存在处理过程中的死锁或者其他性能问题。
如果在LR坛子里讨论这个，就是如何实现并发的问题了。并发可以从2方面讲，一是需要在LR里设置集合点，使所有虚拟用户在集合点进行集合，然后再同一时刻发出请求；二是在服务器的一段时间内，同时驻留多少数量级的在线用户，这个需要脚本录制尽量符合真实用户的操作（也就是多加合理的思考时间），然后每个虚拟用户迭代或者设置场景的持续时间达到这个目的。
另外，你上文提到的“服务器TPS = 1000”是错误的说法，场景监视器中的tps，只是场景执行过程中，1秒完成的事物数，可以侧面反映出服务器处理的速度，但是这并不是真正的数据。
tps达到1000，当然不能说是并发1000，你的脚本简单的很，那么你一个虚拟用户在1秒内完成的事物数就有可能多个；那么如果是操作比较多的虚拟用户呢？？相同的场景，tps肯定少的可怜，那么你就说服务器并发不行么？ 即使设置了集合点，也并不能真正做到同时发出请求吧。。。 原帖由 qiguojie 于 2010-4-14 11:05 发表 http://bbs.51testing.com/images/common/back.gif
看楼主写的之后比较晕。。
并发从性能测试的角度上来讲，应该是在同一时刻，向某个应用、某个入口或某个数据表发送多条操作，来验证是否存在处理过程中的死锁或者其他性能问题。
如果在LR坛子里讨论这个，就是 ...
想版主所说的并发 我可不可以 理解 如果不设置并发点 和并发页面 的话算不上是并发 对吗？？
但是 如果我跑仅仅是 一个单页面不设置 并发点100用户不停的跑TPS = 1000 那么这样 该怎么算呢？？？
或者说 这页不算严格意义上的并发？？？
[ 本帖最后由 htlg 于 2010-4-14 13:44 编辑 ] 个人觉得lr很难做到真正模拟瞬间并发， 其实 我对并发 概念 并不是太清楚
用户10 在一秒内 访问同页面10次TPS100 并发为10还是100呢？
设置并发点集合人数10人
用户组1 10人 全部集合 在一秒内 访问同页面1次TPS 10
用户组2 10人 在一秒内 访问同页面10次 TPS 100
场景内 2组 跑的是 相同步骤一个设置集合点 一个没有设置而已 并发为10 20 还是110呢？
还是什么呢？
因为我平时 设置并发的时候 并不会100%设置
还是 说我 开始 测试 设计思路 就有错误呢？？ 严格意义上的并发，就是算发出请求，而不是算完成的请求（个人意见，欢迎拍砖）。
说些更实际的，你知道在单位时间内到达服务端的请求数么？这才是服务端真正的压力所在。如同5楼说的，即使设置集合点，LR也不可能同时发出这些请求给服务端，再考虑网络传输等其他因素，到达服务端是肯定有先后的。
“如果我跑仅仅是 一个单页面不设置 并发点100用户不停的跑TPS = 1000 那么这样 该怎么算呢？”
tps不能算就是肯定不能算，tps是已经完成的事务，不是服务端正在处理的事务数。tps是一个lr的监控数据，粗略统计的话可以算做服务端的一个处理性能参数，吞吐能力。
那么，在服务端的压力怎么计算，我们通常都说多少人并发，而不是多少并发是为什么？楼主可以想想。其实测试始终还是一个实践活动，设计测试时我们要尽量模拟真实用户操作，所以才是多少人并发，而不是多少并发。 其实 我也清楚 TPS 是 该秒内一般 是 从发送请求 到TTLS 服务器返回最后一个数据位置 的请求数
并发 是 服务器 MS 内接受同一页面的多少服务器时间是MS 而 并是我们说的S
我这里并发 是只 客户并发出的请求
只是 我概念比较模糊所以 把 比较看似正确的 答案 拿 出来 讨论
我真正要结果就是我能 明确这 并发 实际上的意思
我只想知道 访问 单 页面的 时候 TPS可不可以作为该秒的并发最大数
被人找去做下事情思路忘记了。。。。。。。 在LoadRunner的虚拟用户中，术语Concurrent与Simultaneous存在一些区别
Concurrent是指在同一个场景中参与运行的虚拟用户，而Simultaneous与同步点（rendezvous point）的关系更密切，是指在同一时刻一起执行某个任务的虚拟用户 。。。。。。
做下 实际测试 然后对一些 理论知识模糊起来了 谁能举个详细的例子给我解释下啊
或者 对我下面 说者例子 做下解释
有10个小孩 小1到 小5有快有慢 在1小时吃了20个苹果
小孩6-10同时开始吃到吃完在1小时内吃了5个（1人一个）
把每吃一掉个苹果当 一次请求完成一次事务响应那么 这个小时内 并发是多少呢？
[ 本帖最后由 htlg 于 2010-4-14 16:24 编辑 ] 自己扛上去::JFBQ00125080410a::: ::JFBQ00125080410a::: 我觉得LZ有点绕，还是现实点，根据客户需求来：
客户说我不要求每个步骤都同时发出请求，只要求在这一个小时内，有5个用户在上面操作，那么不必去管什么集合点什么的，那就直接跑；
客户说我要求每个步骤都要保证有5个用户同时请求，那么就在每个步骤加上集合点，尽管不是真正意义上的同时请求，也是最大化的同时了。 ::callphone:::
实际操作和 理论实现是不一样的。。。。
如果你的客户 要求 知道 服务器 最大能处理的并发数呢???? 压力测试？？？
回复 17# 的帖子
是的 莫非你的意思是你的server在同一时间处理的请求数？你的用户没这么专业吧。
一般来说我们只要知道在现有配置下可以承受多少用户就行了。
如果说同一时间处理的请求数的话，看server处理的进程数吧，你那边不断加压，看server中进程数到多少时会死掉，这是不是服务器最大能处理的并发数？ 你说的那个最大承受压力说 不上 严格上 并发 说所以 说 我认为TPS说成最大并发数也没有 多大错误因为 这一秒内 确实处理这么多想同 的页面虽然不是同一MS
页:
[1]
2
