移动性能测试 小菜的性能日记 2 (并发用户?并发请求?)

心向东 · December 16, 2015 · Last by 朱zhu replied at October 06, 2019 · 4340 hits
本帖已被设为精华帖!

时间:x月x日 地点:xx公司测试部 人物:小菜、大鸟

  小菜拿着两份测试报告跑去找大鸟,让他分析为什么同样的并发用户加上think time差距会如此巨大。大鸟笑着说:“你等一下我给你画一张图,你就懂了。”

用户        http请求     服务器      用户        http请求     服务器
😆 |--------💣😵        😆 |--------💣😵
  |--------💣😵        😆 |--------💣😵
😆 |--------💣😵        😆 |--------💣😵
  |--------💣😵        😆 |--------💣😵
😆 |--------💣😵        😆 |--------💣😵

大鸟指着图说道:“服务器的压力并不直接来自于用户 😆,而来自于用户所产生的请求 💣 ,请求 💣 的数量才是影响服务器压力的关键因素“
”你再看看你的测试结果“

50并发用户 😆 ,每个用户 😆 每1秒产生1个请求💣 ,每秒共产生50个请求💣
并发 | 响应时间 | 应用服务器cpu |数据库服务器cpu |TPS |
50  |   1s    |    70%     |      20%     |50 |
100  |   1.3s   |    95%     |      30%     |75 |
200  |   2.9s   |    99%     |      30%     |70 |
500  |   7s    |    99%     |      30%     |71 |

500并发用户 😆(9秒think time) 每个用户 😆 10秒产生1个请求💣 ,每秒共产生50个请求💣
并发 | 响应时间 | 应用服务器cpu |数据库服务器cpu |TPS |
50  |   0.8s   |    10%     |      5%       |5   |
100  |   0.9s   |    20%     |      10%     |10 |
200  |   0.9s   |    20%     |      10%     |20 |
500  |   1s    |    70%     |      20%     |50 |

“这下我知道怎么回事了,判断一个应用是否满足性能指标,只需要判断这个应用每秒能处理多少请求和用户并没有直接关系。”小菜点着头说。
“那A接口每天会有50000个请求,那么它的压力就是50000/(3600*24)=0.6笔/s... ”小菜挠着头感觉有哪里不对。
大鸟用笔狠狠的敲了小菜的脑袋说:“你这笨蛋,难道你的接口24小时都有人用吗?一般服务器的业务大多发生在工作日9:00˜17:00 ,那么你起码也要这么算50000/(3600*8),当然业务的产生肯定不是平均的,这时候我们会使用80/20原则来计算平均峰值来作为我们的指标。”
80/20峰值公式:80%的业务是在20%的业务时间内完成的
"所以A接口的指标应该是(50000*80%)/(3600*8*20%)=28笔/s"
“大鸟果然是大鸟,这下我明白了。我以前也不懂,一直听人说并发是衡量系统性能的指标,原来这个并发不是指用户,而是指请求啊

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
共收到 40 条回复 时间 点赞

你是我的偶像

瞠目结舌!!!

28原则也不能硬套, 用生产数据做统计的话, 跟28原则差距还是很大的. 甚至有可能是1:100
loadrunner设计等待时间和用户数是为了让测试工程师和产品对真实的场景有个数字感知. 那个所谓的并发用户数是很不准确的.
真实的tps需要用底层的qps来计算. 而业务应该承受的并发需要根据这个基础结合场景自己去推算.
loadrunner的结果偏差太大.

#3楼 @seveniruby 平稳的业务系统使用28原则算出的是tps的可能峰值,肯定会比实际要大一些,对于小菜来说先硬套一下未尝不可,等他长成大鸟自然会有自己的思路

这个二八学到了,不过只是一个基本的理论,对于小菜来说多次实际数据比较,就会摸清公司业务的资源分配概率。赞一个

膜拜!

后面的教程是否可以脱离lr的范畴。。😄

#7楼 @284772894 本来就不是LR的范畴啊.....

场景设计各有各的方法啊

一楼又被强占

持续关注。。。。赞东哥~

必须膜拜一下!~

#9楼 @face_south 我的个人觉得用户数 根本就是个伪数据,你的压力和用户数没有直接关系 和用户行为有关系,所以应该分析的是用户行为而非用户数

仔细读,品一品,期待第三篇

@dongdong 恩 多业务业务量占比不一样的情况还是要考虑用户数去分配业务占比的吧

#14楼 @face_south 这个后面会说到,并不需要用户这个数据去分配业务比例

东哥威武

写得生动形象。

有意思

写的棒棒的,趣味和知识并重,持续学习中

厉害

比较有趣味,和那个大话设计模式一样,写得不错对新人一定有帮助,核算可以按秒,并发压力也不一定是单位是秒,以单位时间内,批量事务的处理产生后的数据,然后折算吞吐能力。

你是我的偶像

#3楼 @seveniruby 那你具体如何做计算呢,QPS和TPS

#12楼 @dongdong可以这么说吗,是请求,是业务场景或者是用户行为所提出的请求,来考虑并发数,而不是用户个数,个数是没有直接关系的

有趣!

—— 来自TesterHome官方 安卓客户端

“判断一个应用是否满足性能指标,只需要判断这个应用每秒能处理多少请求和用户并没有直接关系”,这个观点值得商榷
如果客户代表一个session,并发多个session对服务器有木有直接影响?
并发用户和并发请求应该是2个概念,不能混为一谈吧。。。

#26楼 @quqing 要生成大量的在线session 只要一直操作某个操作就可以了,比如登录. 我并发1个用户只要不停做登录操作也能在服务器端生成多个session的。

#26楼 @quqing 主要大家看到的并发 是 工具端的,而真正服务器的并发 只有并发请求 没有并发用户这个概念。

并发生成和非并发生成是不一样的概念,这个倒不是主要的,我们讨论是否和用户有关哈
如果单纯是接口性能的测试,你说的可能是对的;
如果是模拟用户行为的业务性能测试,应该和用户也有关,每个用户有自己的session,session里面的读写操作也会影响性能,这不能单纯的用某个请求来衡量了,所以说用户和请求是不同纬度的指标。。。

#26楼 @quqing
可以在单个并发用户线程中模拟n个用户的行为.session是服务器端的,而session会response给客户端相对应的cookie。脚本中可以多次提交登录等操作,让服务器端产生session 并保存服务器端返回的cookie。 在后续的请求中可以依次使用获得的cookie模拟多个用户的行为.所以压力还是看请求的并发量,请求中可以切换不同用户的session就能模拟用户了

#30楼 @dongdong 我还是认为“并发用户和并发请求”是2个维度的概念,如果是基于用户行为的压测,模拟的是用户操作,之后的一系列请求也是基于用户触发的,这个业务场景里面的每个环节都有可能对结果造成影响,在设计场景时也是基于用户的行为的业务场景。这个概念确实比较纠结,因为用户的具体操作确实都是一系列请求发起的,而这些请求是非独立的,它们之间可能有耦合关系,它们的载体是用户,所以有些性能测试工具引入了虚拟用户这么一个概念。
“并发不是指用户,而是指请求”,这个结论用于接口的性能测试比较恰当。

#31楼 @quqing
只有并发请求和在线用户 没有并发用户的概念

东哥,你那边还需要性能小菜吗?

虽然我说 “你是我偶像” 这句话并没有什么实际价值,但我还是要以此来表达一下膜拜的心情,好文章就是这样的!

除了用8/2原则外,其实还得关注下,每天的峰值PV,去看下每天峰值PV下的每秒钟请求数是多少。

学习了,有收获,“原来并发并不是指用户数而是请求” 及计算 “80/20峰值公式:80%的业务是在20%的业务时间内完成的
"所以A接口的指标应该是(50000*80%)/(3600*8*20%)=28笔/s"” 这个还是有一定道理的。

心向东 [Topic was deleted] 中提及了此贴 10 Jul 10:39
心向东 [Topic was deleted] 中提及了此贴 10 Jul 10:39
心向东 [Topic was deleted] 中提及了此贴 10 Jul 10:39

80/20峰值公式:80%的业务是在20%的业务时间内完成的
"所以A接口的指标应该是(50000*80%)/(3600*8*20%)=28笔/s"
28笔/s的结果是不是计算错误了?

#40楼 @eyesee_janno 嗯 确实错了 😅

这个峰值是不是等于吞吐量?

心向东 回复

请问一下TPS和QPS到底应该怎么理解呢,好像很多人的说法都不一致。感谢解惑

需要 Sign In 后方可回复, 如果你还没有账号请点击这里 Sign Up