51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 5397|回复: 22
打印 上一主题 下一主题

[原创] 并发基础概念

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2010-4-14 09:39:08 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
并发性能测试的过程,是一个负载测试和压力测试的过程。即逐步增加并发用户数负载,直到系统的瓶颈或者不能接收的性能点,通过综合分析交易执行指标、资源监控等来确定系统并发性能的过程。并发性能测试是负载压力测试中的重要内容。
从一个完整解决方案的角度考虑,并发性能测试概括为以下3类:
应用在客户端性能的测试;
应用在网络上性能的测试;
应用在服务器上性能的测试。


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

使用道具 举报

该用户从未签到

2#
 楼主| 发表于 2010-4-14 10:11:45 | 只看该作者
UPUP 顶
回复 支持 反对

使用道具 举报

该用户从未签到

3#
发表于 2010-4-14 10:35:12 | 只看该作者
我觉得1个用户同时发出10个请求和10个用户同时发出一个请求相比较而言,10个用户同时发出一个请求更能模拟现实情况。
至于时间差问题,受环境限制,肯定会有的,但是现实中也会有时间差吧。
回复 支持 反对

使用道具 举报

  • TA的每日心情
    奋斗
    2015-6-25 18:04
  • 签到天数: 1 天

    连续签到: 1 天

    [LV.1]测试小兵

    4#
    发表于 2010-4-14 11:05:37 | 只看该作者
    看楼主写的之后比较晕。。

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

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

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

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

    使用道具 举报

    该用户从未签到

    5#
    发表于 2010-4-14 13:13:00 | 只看该作者
    即使设置了集合点,也并不能真正做到同时发出请求吧。。。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    6#
     楼主| 发表于 2010-4-14 13:42:41 | 只看该作者
    原帖由 qiguojie 于 2010-4-14 11:05 发表
    看楼主写的之后比较晕。。

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

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


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

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

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

    [ 本帖最后由 htlg 于 2010-4-14 13:44 编辑 ]
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    7#
    发表于 2010-4-14 14:23:00 | 只看该作者
    个人觉得lr很难做到真正模拟瞬间并发,
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    8#
     楼主| 发表于 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%设置

    还是 说我 开始 测试 设计思路 就有错误呢??
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    奋斗
    2015-6-25 18:04
  • 签到天数: 1 天

    连续签到: 1 天

    [LV.1]测试小兵

    9#
    发表于 2010-4-14 14:36:46 | 只看该作者
    严格意义上的并发,就是算发出请求,而不是算完成的请求(个人意见,欢迎拍砖)。

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

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

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

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

    使用道具 举报

    该用户从未签到

    10#
     楼主| 发表于 2010-4-14 16:02:41 | 只看该作者
    其实 我也清楚 TPS 是 该秒内  一般 是 从发送请求 到TTLS   服务器返回最后一个数据位置 的请求数

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


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


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

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

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

    使用道具 举报

    该用户从未签到

    11#
    发表于 2010-4-14 16:13:25 | 只看该作者
    在LoadRunner的虚拟用户中,术语Concurrent与Simultaneous存在一些区别
    Concurrent是指在同一个场景中参与运行的虚拟用户,而Simultaneous与同步点(rendezvous point)的关系更密切,是指在同一时刻一起执行某个任务的虚拟用户
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    12#
     楼主| 发表于 2010-4-14 16:17:12 | 只看该作者
    。。。。。。
    做下 实际测试   然后  对一些 理论知识模糊起来了
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    13#
     楼主| 发表于 2010-4-14 16:20:49 | 只看该作者
    谁能举个详细的例子给我  解释下啊

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

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

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

    [ 本帖最后由 htlg 于 2010-4-14 16:24 编辑 ]
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    14#
     楼主| 发表于 2010-4-15 09:27:49 | 只看该作者
    自己扛上去::JFBQ00125080410a::: ::JFBQ00125080410a:::
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    15#
    发表于 2010-4-15 10:38:26 | 只看该作者
    我觉得LZ有点绕,还是现实点,根据客户需求来:
    客户说我不要求每个步骤都同时发出请求,只要求在这一个小时内,有5个用户在上面操作,那么不必去管什么集合点什么的,那就直接跑;
    客户说我要求每个步骤都要保证有5个用户同时请求,那么就在每个步骤加上集合点,尽管不是真正意义上的同时请求,也是最大化的同时了。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    16#
     楼主| 发表于 2010-4-15 11:06:26 | 只看该作者
    ::callphone:::
    实际操作和 理论实现是不一样的。。。。

    如果你的客户 要求 知道 服务器 最大能处理的并发数呢????
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    17#
    发表于 2010-4-15 16:01:38 | 只看该作者
    压力测试???
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    18#
     楼主| 发表于 2010-4-16 08:34:09 | 只看该作者

    回复 17# 的帖子

    是的
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    19#
    发表于 2010-4-16 09:37:05 | 只看该作者
    莫非你的意思是你的server在同一时间处理的请求数?
    你的用户没这么专业吧。
    一般来说我们只要知道在现有配置下可以承受多少用户就行了。

    如果说同一时间处理的请求数的话,看server处理的进程数吧,你那边不断加压,看server中进程数到多少时会死掉,这是不是服务器最大能处理的并发数?
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    20#
     楼主| 发表于 2010-4-16 14:29:38 | 只看该作者
    你说的那个  最大承受压力  说 不上 严格上 并发 说  所以 说 我认为TPS  说成  最大并发数  也没有 多大错误  因为 这一秒内 确实处理这么多想同 的页面  虽然不是同一MS
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

    站长推荐上一条 /1 下一条

    小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

    GMT+8, 2024-11-9 05:49 , Processed in 0.095547 second(s), 27 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

    快速回复 返回顶部 返回列表