背景

接口一压测，QPS 上不去，很多团队第一反应就是查数据库。这当然没问题，但如果每次都只盯着 SQL，很容易漏掉一些同样常见的瓶颈。

我之前做过几次压测复盘，发现真正影响 QPS 的因素经常不止一个，而且往往有一些很容易被忽略。

1. 线程池配置不合理

如果接口本身依赖外部服务或者有一定阻塞时间，线程池配置就会直接影响吞吐。

比较典型的问题有：

• 工作线程太少
• 队列太长，吞掉了短期抖动
• 拒绝策略没有暴露出真实压力

很多时候不是系统“扛不住”，而是请求在内部排队太久，导致看起来 QPS 上不去。

2. 连接池成为隐性瓶颈

数据库连接池、HTTP 连接池、Redis 连接池，只要有一个配置偏保守，都可能限制整体吞吐。

这种问题的特点是：

• CPU 还没打满
• 数据库本身也没到极限
• 但请求吞吐始终上不去

本质上是业务线程在等连接，而不是在真正执行。

3. 外部依赖的波动被低估了

压测并不只是在测你自己。如果请求链路里有 RPC、HTTP、缓存回源、消息确认等操作，任何一个外部环节抖一下，整体吞吐都会受影响。

尤其是高并发下，哪怕单次波动只多几十毫秒，累计起来也会很明显。

4. 日志和监控本身带来了额外开销

这个点经常被忽略。排查性能问题时，大家喜欢把日志打得很全，但在高并发压测下，频繁的同步日志、复杂的埋点和过重的链路追踪都有可能拖慢接口。

所以压测环境里最好区分：

• 必要监控
• 调试用额外日志

否则你可能测到的是“排查系统本身”的性能上限。

5. 压测脚本和流量模型不够真实

还有一种情况，不是系统扛不住，而是压测方式本身不合理。比如：

• 所有请求都打到同一个热点数据
• 用户登录态复用方式不符合真实场景
• 突发流量模型和线上完全不同

这种情况下，得出的瓶颈结论也容易偏。

总结

QPS 上不去，数据库当然值得查，但不应该只查数据库。线程池、连接池、外部依赖、日志开销、压测模型，这些都可能成为真正瓶颈。

我越来越觉得，性能排查里最怕的不是系统慢，而是还没把瓶颈范围看完整就急着下结论。