实战出真知
举例，日常操作步骤 ， 1、打开首页 2、登录 3、点击品类 4、选择商品 5、点击购买 6、订单详情 7、支付成功 8、退出 ，总请求数假设为100
1、单个在线用户的 TPS -----计算从生产日志中找到实际步骤中用户实际操作以上流程的时间，假设为250S 小结：- 如果你把事务 T 设置为每个请求一个事务，一个用户需要的就是 0.4TPS
- 如果你把事务定义到每个业务操作的级别，总共是 7 个业务操作，而这 7 个业务操作是在 250 秒内完成的，那对应的 TPS 就是
- 请求级的 TPS：
- 如果平均时间在1小时完成，则请求级的 TPS： （备注：注意峰值时间不一样，得出的tps差异非常大） (100000(用户) × 100(请求数)) ÷ 3600(秒) ≈ 2, 777.78(TPS)
- 请求级的 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
以上知识点主要参考极客时间-高楼性能测试实战