一台服务器的TPS不是从CPU核数或内存大小直接算出来的，而是用贴近业务的压测跑出来的：TPS=有效压测时间内完成的事务数÷有效压测秒数，再结合错误率、P95/P99响应时间和资源瓶颈一起看。
很多人搜“服务器TPS怎么计算”，真正卡住的往往不是公式，而是事务边界怎么划、压测时长怎么算、工具给的Requests/sec能不能直接当TPS，把服务器想成一个收银台：收银员数量只是表面，顾客点单复杂度、后厨出餐速度、排队方式都会影响每秒能结几单，TPS也一样，配置单只是起点,压测和瓶颈定位才是答案。
服务器TPS计算公式：分子分母先对齐
先把公式写清楚：
- TPS = 完成事务数 ÷ 有效压测时长（秒）
- 有效压测时长 = 总压测时长 – 预热时间 – 降压停止时间
- 事务边界 = 业务上完整的一次操作，不是随便一个HTTP请求
下单”这个事务，可能包含扣库存、写订单、发消息三个请求，压测工具如果只统计HTTP请求数，那得到的是请求速率，不是下单TPS，一个事务发三个请求,就要按事务控制器或业务日志把三个请求合成一次事务。
下面这张表是示例值，只用于演示公式,不是行业标准：
| 项目 | 示例值 | 说明 |
|---|---|---|
| 总压测时长 | 300秒 | 包含预热和停止阶段 |
| 预热时间 | 30秒 | 缓存、连接池、JIT还没稳定，不计入 |
| 降压停止时间 | 20秒 | 压测机停止发压阶段，不计入 |
| 有效压测时长 | 250秒 | 300-30-20 |
| 完成事务数 | 500000 | 按业务事务统计 |
| TPS | 2000 | 500000÷250 |
公式简单，难的是分子分母别掺水，分子把请求数当事务数，TPS会虚高；分母把预热和降压算进去,TPS会被拉低。
服务器TPS和QPS有什么区别
这两个指标经常被混着写，QPS偏“请求/查询”，TPS偏“完整业务事务”，一个事务可能对应多个QPS,对比看更清楚：
| 指标 | 统计对象 | 常见来源 | 适用场景 |
|---|---|---|---|
| TPS | 完整业务事务 | 压测脚本事务控制器、业务日志 | 下单、支付、登录 |
| QPS | 请求或查询次数 | 网关日志、Nginx日志、压测工具Requests/sec | 查询接口、静态资源 |
压测工具报告里的Requests/sec，在一个事务等于一个请求时，可以近似看作TPS；一个事务多个请求时，不能直接画等号，写容量报告前，先把事务边界写清楚,比堆数字有用。
并发数、响应时间与TPS的换算
稳态下可以用一个近似关系：并发数 ≈ TPS × 平均响应时间（秒），反过来就是 TPS ≈ 并发数 ÷ 平均响应时间（秒），注意响应时间单位是秒,不是毫秒。
- 并发200、平均响应时间100ms=0.1秒，理论TPS约2000
- 平均响应时间被长尾请求拉高，实际TPS会低于理论值
- 连接池、数据库锁、线程池队列会让理论值跑不满
这个换算适合做快速估算，不能替代压测，平均响应时间好看，P99很高时,用户体感依然差。
如何测试服务器TPS：从压测脚本到结果判定
压测前先定业务模型
- 选核心业务接口，别拿健康检查页当业务压
- 写清事务边界：一个事务包含哪些请求、哪些步骤
- 准备接近真实的数据量和缓存状态，避免全命中缓存
- 明确目标：摸瓶颈、验容量，还是对比两个版本
压测不是把并发数拉满就完事，业务模型不对,TPS再高也只是实验室数字。
常用工具与命令示例
wrk适合HTTP接口压测,命令示例：
wrk -t4 -c200 -d60s --latency http://127.0.0.1:8080/api/order
ab适合快速摸底：
ab -n 10000 -c 100 http://127.0.0.1:8080/api/order
JMeter用事务控制器把多个请求合成一个事务，再看聚合报告里的Throughput和Error%，k6、Locust适合脚本化、带业务链路的场景。
压测机和被测机尽量分开,客户端文件句柄和端口要提前调：
ulimit -n 65535 ss -s
工具自己也可能成为瓶颈，压测机CPU打满时,被测服务器的TPS会被低估。
结果看哪几个指标
| 指标 | 看什么 | 判定 |
|---|---|---|
| TPS | 稳态段均值 | 不看一两秒峰值 |
| 错误率 | 非2xx、超时比例 | 错误率上来，TPS没有意义 |
| P95/P99 | 长尾延迟 | 用户体感 |
| CPU/内存 | 是否接近打满 | 定位瓶颈 |
| 磁盘IO/网络 | iostat、sar | 是否到配额 |
| 连接数 | ss、数据库连接池 | 是否在排队 |
业内专家指出，压测报告只写峰值TPS、不写错误率和P99，参考价值有限，稳态段能稳住、错误率可控、长尾延迟可接受,这个TPS才值得写进容量表。
一台服务器TPS多少算正常：别只看绝对值
没有统一答案，行业共识认为，TPS取决于业务逻辑、数据库写入、缓存命中率、连接池和网络路径，纯内存计算接口和带多表写入的接口,TPS不在一个量级。
- 先看同业务基线：版本升级前后、机器扩容前后的对比
- 再看资源余量：CPU到较高水位时，TPS是否还能线性增长
- 最后看错误率和P99：TPS高但错误率高，是假容量
- 简单查询类接口TPS可以很高，但业务价值有限
- 复杂事务接口TPS低一些很正常，关键看瓶颈是否可解释
一台服务器TPS多少算正常”要加定语：什么业务、什么数据量、什么响应时间要求，离开这些谈绝对值,容易变成数字游戏。
云服务器TPS怎么计算，和物理机差在哪
云服务器同样用压测公式,但要多看几个配额：
- 突发型、共享型实例有CPU积分，短时压测高，持续压测可能掉下来
- 云盘有IOPS和吞吐配额，数据库写多的业务先看云盘
- 网络带宽和PPS有限制，跨可用区调用会增加延迟
- 按量付费实例做压测，实例费和流量费要一起算进成本
操作路径不复杂：压测时同步打开云监控，盯CPU积分余额、云盘IOPS、网络出带宽，再和压测时间轴对齐，据公开的云厂商SLA文档，不同实例规格的网络和存储性能有明确上限，压测结果超过上限时先怀疑配额,不要先怀疑代码。
机房跨地域部署时，TPS为什么要打折
同城同可用区RTT低，跨地域RTT高，TPS会受影响，TLS握手、TCP慢启动、长连接复用、跨地域数据库同步,都会放大延迟。
压测机要放在真实用户侧或同地域，不要拿本机内网压测结果当跨地域容量，跨地域带宽通常按流量计费，压测流量别跑飞,压测计划里把流量成本列出来。
TPS低怎么排查：先看时间花在哪
TPS上不去，别急着加CPU,先按下面顺序看：
top -Hp <pid>看线程级CPU，找热点线程vmstat 1看运行队列、上下文切换、swapiostat -x 1看磁盘await和%utilss -s看连接数、TIME_WAITsar -n DEV 1看网络吞吐和丢包- 数据库慢查询、锁等待、连接池等待
- 应用日志里的GC停顿、线程池队列积压
排查顺序先确认事务边界和错误率，再看资源，再看依赖，TPS低不一定是CPU不够，可能是连接池只有几十个、数据库锁等待、磁盘IO到配额，每次只改一个变量，改完复测,才能把原因和结果对上。
一台服务器的TPS计算，公式只是壳，事务边界、有效时长、错误率和P99才是肉，把压测设计做对，再谈容量和采购,数字才有意义。
服务器TPS计算常见问题
压测得到的TPS能直接当线上容量吗？
不能直接等同，压测环境的数据量、缓存状态、网络路径和线上有差异，常见做法是留余量，按压测稳态TPS的较大比例折算，再用线上监控修正，前提是错误率和P99先达标,否则容量数字虚高。
没有压测环境，能不能用日志估算服务器TPS？
可以粗估，按业务日志统计完整事务数，除以有效时间窗口，剔除发布、重启、促销尖峰，日志里要能识别事务边界，比如订单号加状态流转，估算结果适合做趋势对比,不适合替代压测验收。
云服务器TPS怎么计算才不算白花钱？
先定事务边界，再用按量付费实例做短时压测，监控CPU积分、云盘IOPS和网络带宽，压测结束及时释放，把稳态TPS、P99和单位时间成本放在一张表里对比，以业务错误率达标为前提选规格，云服务器TPS不是规格越高越高,瓶颈常在磁盘和网络配额。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/782809.html
