springboot 单机 qps 只有 2000 合理吗？

passer9527 · 1 天前 · 1587 次点击

我们用的 springcloud 那一套，部署在阿里云的 ecs 上。

ecs 配置：4c 8g
程序流程：从 rds (mysql) 中获取数据，放入 redis ，然后做 vo 转换，返回。如果有 redis 有数据，就会直接返回，不会从 mysql 中获取。

目前结果是单机 qps 只能到 2000 ，超过 3000 之后，机器负载就会很高，比如 cpu 超过 70%，内存也超过 70%。

我们高峰 qps 有 3w ，感觉只能加很多机器才能抗住。

我的问题是：springboot 的单机 qps 这么低吗？

18 条回复 • 2021-11-22 12:55:19 +08:00

xbh1794970183564 1 天前

3W 你们指望几台机器就顶住吗。。。

wudaye 1 天前

排查过瓶颈在哪吗？做过 tomcat 调优吗？

moshiyeap100 1 天前

如果不是简单查询接口，我觉得还算合理的，我们的核心业务接口单机 qps 估计 400 都不到。。。。

fighterhit 1 天前

听听楼下大佬怎么说

mind3x 1 天前 via Android

Spring Boot 什么版本？同步还是异步(WebFlux)？ Redis 命中率多高？ JVM heap 使用如何? GC 开销占多少？

reeco 1 天前 via iPhone

信息太少了，没法评估

coderbbb 1 天前

盲猜。按你说的程序流程的话，CPU 大头应该在 VO 转换上，建议把转换后的 VO 缓存。另外，还得看具体业务，比如 VO 的更新频率高不高，缓存命中率能到多少。

Salticey 1 天前

合理吧，我之前有压过一个和你说得类似的模块，还是 16C16G 的，但是是容器部署的（我晓得性能会损失多少），单纯命中缓存的数据 tps 能到 3700 ，再往上 cpu 打满直接宕机了。

mazyi 1 天前

就看 vo 转换要多少 cpu 了，一个字段还是一百个字段都不一样

lixintcwdsg 1 天前 6

不合理，一般来说 QPS200 CPU70%，大概率存在大量线程切换，检查一下几个地方
1. spring boot 线程数是不是满了，自带 tomcat 默认 200 ，如果满了说明后端处理太慢了。
2. 看一下你的 mysql 线程池大小多少，是不是默认的 8 。
3. 看一下你的 mysql 每条查询到底多少毫秒，开一下 druid 这类链接池监控就行，看看是不是 mysql 查询存在瓶颈。
4. 开 jprofile 之类的工具，在线看一下 CPU 事件消耗在哪里，大概是 mysql 引起的线程等待

可能的处理方案：
1. 如果 mysql 存在瓶颈，建议把 spring boot 的线程数调低，高了毫无意义。
2. mysql 查询快，你可以缩小你的 mysql 线程池数量，反之扩大。
3. redis 确保用异步驱动不要用 jedis
4. 客户端是离散的还是集中的，如果固定一些极其请求你这个服务，http keep-alive 记得开。

最后，你这类服务如果要用 java ，不建议 spring boot 。至少不要用同步的 jdbc ，该用异步数据库驱动+异步 redis 驱动+少线程（一般都是基于 netty ）的 web 容器。比如干脆 vert.x
当然这个涉及到技术选型，可能你说了不算。还有一个方案你可以参考，就是把 spring boot 不要自己接 http 请求，spring boot 就启动一个 netty 就好了，netty 负责 http 编解码和 vo 转换部分，netty 和 spring boot 通过 applicationContext 交互。至少保证线程数不太多，CPU 也不会飙多高，你专心调整的 mysql 线程池到一个合理数量。
最后，CPU 飙高说来说起大概率还是线程太多的问题～～