移动性能测试 小菜的性能日记 2 (并发用户？并发请求？)
时间：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"
“大鸟果然是大鸟，这下我明白了。我以前也不懂，一直听人说并发是衡量系统性能的指标，原来这个并发不是指用户，而是指请求啊”
你是我的偶像
瞠目结舌！！！
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
有趣！
—— 来自 TesterHome 官方 安卓客户端
“判断一个应用是否满足性能指标，只需要判断这个应用每秒能处理多少请求和用户并没有直接关系”，这个观点值得商榷
如果客户代表一个 session，并发多个 session 对服务器有木有直接影响？
并发用户和并发请求应该是 2 个概念，不能混为一谈吧。。。
并发生成和非并发生成是不一样的概念，这个倒不是主要的，我们讨论是否和用户有关哈
如果单纯是接口性能的测试，你说的可能是对的；
如果是模拟用户行为的业务性能测试，应该和用户也有关，每个用户有自己的 session，session 里面的读写操作也会影响性能，这不能单纯的用某个请求来衡量了，所以说用户和请求是不同纬度的指标。。。
东哥，你那边还需要性能小菜吗？
虽然我说 “你是我偶像” 这句话并没有什么实际价值，但我还是要以此来表达一下膜拜的心情，好文章就是这样的！
除了用 8/2 原则外，其实还得关注下，每天的峰值 PV，去看下每天峰值 PV 下的每秒钟请求数是多少。
学习了，有收获，“原来并发并不是指用户数而是请求” 及计算 “80/20 峰值公式：80% 的业务是在 20% 的业务时间内完成的
"所以 A 接口的指标应该是（50000*80%）/（3600*8*20%）＝28 笔/s"” 这个还是有一定道理的。
80/20 峰值公式：80% 的业务是在 20% 的业务时间内完成的
"所以 A 接口的指标应该是（50000*80%）/（3600*8*20%）＝28 笔/s"
28 笔/s 的结果是不是计算错误了？
#40 楼 @eyesee_janno 嗯 确实错了 
这个峰值是不是等于吞吐量？
