并发基础概念

htlg · 发表于 2010-4-14 09:39:08

并发性能测试的过程，是一个负载测试和压力测试的过程。即逐步增加并发用户数负载，直到系统的瓶颈或者不能接收的性能点，通过综合分析交易执行指标、资源监控等来确定系统并发性能的过程。并发性能测试是负载压力测试中的重要内容。
从一个完整解决方案的角度考虑，并发性能测试概括为以下3类：
应用在客户端性能的测试；
应用在网络上性能的测试；
应用在服务器上性能的测试。

这个是网上找到的比较笼统的概念
个人理解：并发是每个用户在当秒钟发出的请求10个  是否可以说这个用户并发是10呢？
   我觉得还存在一个时间差的问题    1 个用户发出每秒发 10 请求  和 10个用户每秒发出1 个请求时有区别的大家知道的
现在  一个用户一个请求发出和 1个用户同时发出10 个请求也是应该有区别的  个人觉得
例如：LR 我设置思考时间为0 100个用户 1秒了  服务器TPS = 1000 服务器这秒内处理 1000个请求  那么我可以说这秒并发就1000吗？？
因为用户行为是  请求完成再次请求的

htlg · 发表于 2010-4-14 10:11:45

UPUP 顶

JonnyGu · 发表于 2010-4-14 10:35:12

我觉得1个用户同时发出10个请求和10个用户同时发出一个请求相比较而言，10个用户同时发出一个请求更能模拟现实情况。
至于时间差问题，受环境限制，肯定会有的，但是现实中也会有时间差吧。

qiguojie · 发表于 2010-4-14 11:05:37

看楼主写的之后比较晕。。

并发从性能测试的角度上来讲，应该是在同一时刻，向某个应用、某个入口或某个数据表发送多条操作，来验证是否存在处理过程中的死锁或者其他性能问题。

如果在LR坛子里讨论这个，就是如何实现并发的问题了。并发可以从2方面讲，一是需要在LR里设置集合点，使所有虚拟用户在集合点进行集合，然后再同一时刻发出请求；二是在服务器的一段时间内，同时驻留多少数量级的在线用户，这个需要脚本录制尽量符合真实用户的操作（也就是多加合理的思考时间），然后每个虚拟用户迭代或者设置场景的持续时间达到这个目的。

另外，你上文提到的“服务器TPS = 1000”是错误的说法，场景监视器中的tps，只是场景执行过程中，1秒完成的事物数，可以侧面反映出服务器处理的速度，但是这并不是真正的数据。

tps达到1000，当然不能说是并发1000，你的脚本简单的很，那么你一个虚拟用户在1秒内完成的事物数就有可能多个；那么如果是操作比较多的虚拟用户呢？？相同的场景，tps肯定少的可怜，那么你就说服务器并发不行么？

JonnyGu · 发表于 2010-4-14 13:13:00

即使设置了集合点，也并不能真正做到同时发出请求吧。。。

htlg · 发表于 2010-4-14 13:42:41

原帖由 qiguojie 于 2010-4-14 11:05 发表
看楼主写的之后比较晕。。

并发从性能测试的角度上来讲，应该是在同一时刻，向某个应用、某个入口或某个数据表发送多条操作，来验证是否存在处理过程中的死锁或者其他性能问题。

如果在LR坛子里讨论这个，就是 ...

想版主所说的并发我可不可以理解如果不设置并发点和并发页面的话算不上是并发对吗？？

但是如果我跑仅仅是一个单页面不设置并发点 100用户不停的跑 TPS = 1000 那么这样该怎么算呢？？？

或者说这页不算严格意义上的并发？？？

[ 本帖最后由 htlg 于 2010-4-14 13:44 编辑 ]

liusiyan · 发表于 2010-4-14 14:23:00

个人觉得lr很难做到真正模拟瞬间并发，

htlg · 发表于 2010-4-14 14:24:07

其实我对并发概念并不是太清楚
用户10 在一秒内访问同页面10次  TPS100    并发为10  还是100呢？

设置并发点  集合人数10人
用户组1 10人全部集合在一秒内访问同页面1次  TPS 10
用户组2 10人在一秒内访问同页面10次       TPS 100
场景内 2组跑的是相同步骤  一个设置集合点一个没有设置而已并发为10 20 还是110呢？
还是什么呢？

因为我  平时设置并发的时候并不会100%设置

还是说我开始测试设计思路就有错误呢？？

qiguojie · 发表于 2010-4-14 14:36:46

严格意义上的并发，就是算发出请求，而不是算完成的请求（个人意见，欢迎拍砖）。

说些更实际的，你知道在单位时间内到达服务端的请求数么？这才是服务端真正的压力所在。如同5楼说的，即使设置集合点，LR也不可能同时发出这些请求给服务端，再考虑网络传输等其他因素，到达服务端是肯定有先后的。

“如果我跑仅仅是一个单页面不设置并发点 100用户不停的跑 TPS = 1000 那么这样该怎么算呢？”

tps不能算就是肯定不能算，tps是已经完成的事务，不是服务端正在处理的事务数。tps是一个lr的监控数据，粗略统计的话可以算做服务端的一个处理性能参数，吞吐能力。

那么，在服务端的压力怎么计算，我们通常都说多少人并发，而不是多少并发是为什么？楼主可以想想。其实测试始终还是一个实践活动，设计测试时我们要尽量模拟真实用户操作，所以才是多少人并发，而不是多少并发。

htlg · 发表于 2010-4-14 16:02:41

其实我也清楚 TPS 是该秒内  一般是从发送请求到TTLS 服务器返回最后一个数据位置的请求数

并发是服务器 MS 内接受同一页面的多少  服务器时间是MS 而并是我们说的S

我这里并发是只客户并发出的请求

只是我概念比较模糊  所以把比较看似正确的答案拿出来讨论

我真正要  结果  就是我能明确这并发实际上的意思

我只想知道访问单页面的时候 TPS  可不可以作为该秒的并发最大数
被人找去做下事情  思路忘记了。。。。。。。

TIB · 发表于 2010-4-14 16:13:25

在LoadRunner的虚拟用户中，术语Concurrent与Simultaneous存在一些区别
Concurrent是指在同一个场景中参与运行的虚拟用户，而Simultaneous与同步点（rendezvous point）的关系更密切，是指在同一时刻一起执行某个任务的虚拟用户

htlg · 发表于 2010-4-14 16:17:12

。。。。。。
做下实际测试然后对一些理论知识模糊起来了

htlg · 发表于 2010-4-14 16:20:49

谁能举个详细的例子给我  解释下啊

或者对我下面说者例子做下解释

有10个小孩小1到小5  有快有慢在1小时吃了20个苹果
小孩6-10  同时开始吃到吃完  在1小时内吃了5个  （1人一个）

把每吃一掉个苹果当一次请求完成  一次事务响应  那么这个小时内并发是多少呢？

[ 本帖最后由 htlg 于 2010-4-14 16:24 编辑 ]

htlg · 发表于 2010-4-15 09:27:49

自己扛上去::JFBQ00125080410a::: ::JFBQ00125080410a:::

JonnyGu · 发表于 2010-4-15 10:38:26

我觉得LZ有点绕，还是现实点，根据客户需求来：
客户说我不要求每个步骤都同时发出请求，只要求在这一个小时内，有5个用户在上面操作，那么不必去管什么集合点什么的，那就直接跑；
客户说我要求每个步骤都要保证有5个用户同时请求，那么就在每个步骤加上集合点，尽管不是真正意义上的同时请求，也是最大化的同时了。