RT,QPS指标相关的性能优化

性能优化的核心目标通常就是在 RT响应时间不超标达标的前提下尽可能提升 QPS吞吐量。我直接给你一套通用的性能优化“四步走”方法论你可以像查清单一样对照着去排查第一步定位瓶颈先观测再动手不要凭感觉优化要用数据说话。看监控CPU 飙高还是内存泄漏磁盘 I/O 满了还是网络带宽打满了看链路用ArthasJava或Py-SpyPython等工具抓取在线线程栈看看时间到底耗在哪里。区分“慢”的类型RT 高但 CPU 低大概率是外部 I/O 阻塞查数据库、调第三方 API、读磁盘。RT 高且 CPU 高大概率是内部计算密集复杂循环、序列化/反序列化、GC 频繁。第二步分层优化从外到内按性价比从高到低排序优化层级核心手段预期收益1. 缓存层加Redis本地缓存Caffeine把热数据放在离 CPU 最近的地方。一次磁盘/网络 I/O 约 1-10ms一次内存读取约 0.1ms差距百倍。⭐⭐⭐⭐⭐2. 数据库层检查 SQL 索引是否命中避免SELECT *读写分离分库分表。⭐⭐⭐⭐3. 代码逻辑层并行调用CompletableFuture代替串行批量接口代替循环单查避免大对象频繁创建引发 Full GC。⭐⭐⭐⭐4. 网络传输层数据包体压缩Gzip启用 HTTP/2 多路复用减少不必要的水印/日志打印。⭐⭐⭐第三步压测验证控制变量法优化完一定要压测否则不知道是变好了还是变坏了。单机压测用JMeter或wrk发压观察 QPS 拐点即 RT 突然飙升的那个临界点。常用公式QPS 预估 (单机 QPS) × (机器数量) × (0.7 ~ 0.8 冗余系数)。注意压测时记得把日志级别调为WARN因为DEBUG日志会严重拖垮 QPS吞吐量直接腰斩。第四步异步削峰终极手段如果业务逻辑无法再优化且允许短暂延迟将同步请求改为异步MQ 消息队列。前端快速返回“处理中”后端慢慢消费。效果RT 几乎不变但 QPS 可承受量能翻好几倍因为排队了。特别提醒避坑指南过早优化是万恶之源如果你的 QPS 只有 100优化到 1000 不如加一台机器来得快。连接池/线程池别设太大线程数超过 CPU 核心数过多上下文切换的开销反而会让 QPS下降。一般公式线程数 CPU 核心数 / (1 - 阻塞系数)。监控 RT 的“百分位数”别只看平均 RT平均值会被极端值拉平重点看TP9999% 的请求在多少毫秒内完成。