tps与rt是高并发系统中受资源约束动态平衡的一对核心变量，其关系由并发数耦合（tps≈并发数÷平均rt），rt升高常是tps瓶颈的早期信号，需结合p95/p99等分布指标评估真实稳定性。
吞吐量（TPS）和响应时间（RT）不是孤立数字，而是高并发系统中相互牵制、此消彼长的一对核心变量。理解它们的技术关联，关键在于看清背后的真实瓶颈逻辑——不是“越快越好”或“越多越好”，而是二者在资源约束下的动态平衡。
TPS 和 RT 的本质关系：受制于并发能力与处理效率
TPS 衡量的是单位时间完成的事务数，RT 衡量的是单次事务耗时。两者通过并发数（Concurrent Users / Requests）紧密耦合：
- 理论公式成立：TPS ≈ 并发数 ÷ 平均 RT（单位统一为秒）
- 这意味着：固定并发下，RT 增加 → TPS 必然下降；反之，优化 RT 可直接提升 TPS 上限
- 但该公式只在系统未过载时近似成立；当 RT 显著拉长（如从 50ms 涨到 800ms），往往说明线程阻塞、队列堆积或 GC 频繁，此时 TPS 不再随并发线性增长，甚至开始回落
RT 升高常是 TPS 瓶颈的早期信号
在 Java 服务压测中，RT 往往比 TPS 更早暴露问题：
Java JDK 25
下载
Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。
- 刚起步加压时，TPS 上升、RT 稳定 → 系统健康
- RT 开始缓慢爬升（如从 80ms → 150ms）→ CPU 利用率升高、数据库连接池趋紧、线程上下文切换增多
- RT 急剧跳变（如突增至 2s+）→ 出现排队等待（如 Tomcat accept queue 满、DB connection timeout）、Full GC 触发或锁竞争加剧
- 此时继续加压，TPS 不增反降，系统进入“过载失稳区”
Java 层面影响 TPS/RT 关联的关键因素
这些因素决定了你能否在可控 RT 下维持高 TPS：
- 线程模型：同步阻塞 I/O（如传统 Servlet）会快速耗尽线程池，RT 拉长、TPS 锁死；换成 Netty 或 WebFlux 异步非阻塞，可显著提升单位线程承载力
- 数据库访问：慢 SQL 或缺少索引 → 单次 DB 调用 RT 增加 → 整个事务 RT 上涨 → TPS 下滑；连接池配置不当（maxPoolSize 过小）也会人为制造排队延迟
- JVM 资源：堆内存不足引发频繁 Young GC → 应用停顿（STW）→ RT 波动增大；老年代压力大触发 Full GC → RT 突增、TPS 断崖下跌
- 外部依赖：调用超时设置不合理（如 HTTP client 默认无 timeout）、下游服务 RT 波动，会直接传导并放大本服务的 RT 和失败率
评估时必须看分布，不能只盯平均值
平均 RT 掩盖风险，P95/P99 RT 才反映真实用户体验和系统稳定性：
- 平均 RT 200ms，但 P99 达 2s → 说明 1% 请求严重卡顿，可能是慢查询、锁争用或偶发 GC
- TPS 看似达标，但 P99 RT 持续恶化 → 系统已处于临界状态，稍加压就崩
- 建议压测报告至少包含：TPS、平均 RT、P90/P95 RT、错误率、CPU/Heap 使用率趋势图
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
