实战出真知

举例，日常操作步骤 ， 1、打开首页  2、登录   3、点击品类 4、选择商品 5、点击购买 6、订单详情 7、支付成功 8、退出    ，总请求数假设为100

 
1、单个在线用户的 TPS —–计算从生产日志中找到实际步骤中用户实际操作以上流程的时间，假设为250S 
 
小结：
  • 如果你把事务 T 设置为每个请求一个事务，一个用户需要的就是 0.4TPS  
1(用户) × 100(请求数) ÷ 250(时间窗口) ≈ 0.4(请求数/秒)
  • 如果你把事务定义到每个业务操作的级别，总共是 7 个业务操作，而这 7 个业务操作是在 250 秒内完成的，那对应的 TPS 就是
1(用户) × 7(单业务操作级事务) ÷ 250(时间窗口) ≈ 0.028(TPS)
    
2、多在线用户的 TPS 计算，假设在线用户数为100000，共在60s内完成  (实际操作业务完成时间平均250s，取峰值时间60s类似于秒杀场景)
（备注：用户样本要尽量多，而且比例要到位，样本起码尽量要制定走完整个流程的用户比例和未走完流程的用例比例保持接近。这样才能满足真实用户的操作分布，因为每一个事务流程中的用户的思考时间由于业务的特殊性必然不一致。）
小结：
  •     请求级的 TPS：
(10000(用户) × 100(请求数)) ÷ 60(秒) ≈ 16, 666.67(TPS)
  •       如果平均时间在1小时完成，则请求级的 TPS：  （备注：注意峰值时间不一样，得出的tps差异非常大）
    (100000(用户) × 100(请求数)) ÷ 3600(秒) ≈ 2, 777.78(TPS) 

 

3、用jmeter跑以上流程的时间，查看整个流程时间假设为
  • 请求级的 TPS：
1(用户) × 100(请求数)) ÷ 6(秒) ≈ 16.67(TPS)
小结：
  • 一个没有停顿的用户（并发用户）相当于多少个有停顿的用户  
    16.67 ÷ 0.4 ≈ 41.79
  • 并发度就是   1(并发用户) ÷ 41.79(在线用户) ≈ 2.4%(也即是6/250)
  • 你录制了脚本并且没有设置停顿时间（你可以叫 Think Time 或等待时间），
    如果你想支持的是 10 万在线用户在一小时内完成所有业务，那么支持的对应并发用户数就
    是：100000(在线用户) × 2.4% = 2, 400(并发用户)
  • 而我们一个线程跑出来的请求级的 TPS 是 16.67，要想模拟出 10 万用户的在线，我们需
    要的压力线程数就是：

    2, 777.78(10万在线用户时的请求级TPS) ÷16.67(一个压力线程的请求级TPS) ≈ 167(压力线程)
     
    总结：
    在线用户数和压力线程之间的关系：
    用请求级 TPS 计算：
    压力线程 = (在线用 峰 户 值 数 采 × 样 单 时 用 间 户 段 请求数) ÷ 一个压力线程的请求级TPS
    用单业务操作级 TPS 计算：
    压力线程 = (在线用户 峰 数 值 × 采 单 样 用 时 户 间 业 段 务操作数) ÷ 一个压力线程的业务操作级TPS
    用用户级 TPS 计算：
    压力线程 = (在线用户数× 峰 单 值 用 采 户 样 完 时 整 间 业 段 务数(也就是1) ÷ 一个压力线程的用户级TPS
     
    并发用户数 = 在线用户数 × 有停顿时间的单线程TPS/ 无停顿的单线程TPS
    并发度： 并发用户/在线用户   ×  100
     
    1. 在线用户数。这个值可以从日志中取到；
    2. 在线用户数统计的时间段。这个值也可以从日志中取到；
    3.用户级操作的完整业务流时间（记得多采样一些数据，计算平均时间）。这个值也是从
    日志中取到；
    4. 无停顿时间的完整业务流时间。这个值从压力工具中可以取到；
    5. 单用户完整业务流的请求数。这个值可以从日志中取到。
     
    容量场景： 场景总TPS为1700
    一个用户完整的接口级请求是 11 个，但并不是每一个用户都会完整地走完这 11 个接口。按照业务模型中的比例算下来，100 个 TPS（一个 T 对应
    着一次接口请求）可以支持 54 个并发用户 

     平均单个用户需要的 TPS 是：100 ÷ 54 ≈ 1.85

    并发用户=最大TPS/单用户TPS=1700/100 ÷ 54≈918
    在线用户=并发用户/并发度=918/2.4% ≈ 38250

    具体的结论为：通过容量场景的结论可知，系统 最大 TPS 为 1700，系统可支撑最大 918 并发用户；系统可支撑最大 38250 在线用户。
     

    备注：100 个 TPS（一个 T 对应着一次接口请求）可以支持 54 个并发用户的解释

     

     

    假设 一个有4个业务比例 分别是 25% 25% 25% 25%， 如果是100个TPS ，相当于100 * 25 % = 25，也就是100TPS相当于25个用户 假设一个业务有6个业务分别是 5% 25% 25% 20% 5% 20%， 如果是100个TPS，相当于100 * 25 % =25，也就是100个TPS最大相当于25个用户，如果是使用5%，那么100个TPS，相当于最小5个用户

    所以最大的业务比例是商品搜索的54%， 即最大并发用户数 = max(最大业务比例) * 业务级TPS = 1700 * 54% = 918

     

    以上知识点主要参考极客时间-高楼性能测试实战

原文地址：http://www.cnblogs.com/melodyruo/p/16876334.html

1. 本站所有资源来源于用户上传和网络，如有侵权请邮件联系站长！ 2. 分享目的仅供大家学习和交流，请务用于商业用途! 3. 如果你也有好源码或者教程，可以到用户中心发布，分享有积分奖励和额外收入！ 4. 本站提供的源码、模板、插件等等其他资源，都不包含技术服务请大家谅解！ 5. 如有链接无法下载、失效或广告，请联系管理员处理！ 6. 本站资源售价只是赞助，收取费用仅维持本站的日常运营所需！ 7. 如遇到加密压缩包，默认解压密码为"gltf",如遇到无法解压的请联系管理员！ 8. 因为资源和程序源码均为可复制品，所以不支持任何理由的退款兑现，请斟酌后支付下载 声明：如果标题没有注明"已测试"或者"测试可用"等字样的资源源码均未经过站长测试.特别注意没有标注的源码不保证任何可用性