V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
• 请不要在回答技术问题时复制粘贴 AI 生成的内容
Kontinue
V2EX  ›  程序员

请教 Springboot 接口 RPS 优化问题

  •  
  •   Kontinue · 2022-12-07 09:50:05 +08:00 · 2224 次点击
    这是一个创建于 741 天前的主题,其中的信息可能已经有所发展或是发生改变。

    目前的部署环境如下:

    服务:jdk11 +springboot2.5 JVM 默认配置

    阿里云 ECS 4c 16G * 2 + SLB 做负载均衡 RDS MySQL5.7 2c 8G 单机 Redis 主要做分布式锁

    目前测试下来,TPS avg 500+,峰值 900+,业务异常大主要是 tryLock 没获取到锁直接 return 了。

    领导说这配置理论应该能处理 5000 ,峰值可以到 8000 ?之前冷系统做的多,不太清楚,这个配置可以能到什么量级,虚心求教。sql 基本已做优化,没啥慢 sql 了。

    请问下还有什么优化的方式吗?

    zc04at.png

    29 条回复    2022-12-07 14:53:08 +08:00
    Seulgi
        1
    Seulgi  
       2022-12-07 09:52:59 +08:00
    你领导是在说理论 tps 5000?
    cheng6563
        2
    cheng6563  
       2022-12-07 09:54:49 +08:00
    没用消息队列消峰?那瓶颈基本就在数据库了。
    Kontinue
        3
    Kontinue  
    OP
       2022-12-07 09:55:54 +08:00
    @Seulgi 并发要测个峰值,就是支持的最大限度,理论上应该在 8000 以上才对
    --
    领导原话= =
    Kontinue
        4
    Kontinue  
    OP
       2022-12-07 09:57:45 +08:00
    @cheng6563 没有。
    1. 日常并发估计就几时,就感觉没必要额外加中间件了。
    2. 而且业务要求,这个接口需要同步返回的。
    2han9wen71an
        5
    2han9wen71an  
       2022-12-07 10:06:38 +08:00
    @Kontinue 100QPS 的我觉得同步不太可能,等一手大佬回复
    Seulgi
        6
    Seulgi  
       2022-12-07 10:06:43 +08:00
    @Kontinue 感觉你们领导说 qps,但是你们监控是 tps
    fengpan567
        7
    fengpan567  
       2022-12-07 10:08:49 +08:00
    看看接口的响应时长
    Seulgi
        8
    Seulgi  
       2022-12-07 10:11:04 +08:00
    本身 2c 8g 的 mysql 配置也不算高. 同步峰值不到 1000, 感觉已经差不多了.
    Kontinue
        9
    Kontinue  
    OP
       2022-12-07 10:11:58 +08:00
    @Seulgi 他意思应该是 RPS ,就是每秒处理这么多个吧
    Kontinue
        10
    Kontinue  
    OP
       2022-12-07 10:12:57 +08:00
    @fengpan567 图里写了,正常 100 以内,压测下 avg:320ms
    night98
        11
    night98  
       2022-12-07 10:18:54 +08:00
    2c8g tps 顶天应该在 3-4000 左右,理论和实际肯定有差别,你领导在瞎编
    Kontinue
        12
    Kontinue  
    OP
       2022-12-07 10:21:29 +08:00
    @night98 现在能测到的峰值,TPS 1400 ,QPS 9000
    cheng6563
        13
    cheng6563  
       2022-12-07 10:33:03 +08:00
    那没啥办法咯,MySQL 这类数据库的事务性能就这样了。要么怼高配置要么搞下数据分片咯。
    pangdundun996
        14
    pangdundun996  
       2022-12-07 10:36:42 +08:00
    有 cat 埋点吗?压测看调用耗时,看具体瓶颈在哪里:应用还是 mysql ,mysql 慢的话看负载,基本就知道该怎么优化了。
    而且 QPS 和 TPS 是两码事,你领导要的是 QPS 还是 TPS ?
    fengpan567
        15
    fengpan567  
       2022-12-07 10:43:12 +08:00
    每台部署了几个服务,看能不能加下服务数量? btw ,压测时用 arthas 的 trace 命令看看方法的链路的消耗时长
    Kontinue
        16
    Kontinue  
    OP
       2022-12-07 10:44:42 +08:00
    @fengpan567 一台一个服务,峰值 cpu 已经 90%,再多开也没意义吧?
    Kontinue
        17
    Kontinue  
    OP
       2022-12-07 10:53:42 +08:00
    @pangdundun996 QPS 和 TPS 对于数据库,Q for 查询,T for 事务,那对于一个接口而言指的是什么?我也不太清楚= =
    PlanV
        18
    PlanV  
       2022-12-07 10:55:46 +08:00
    这是什么测试工具啊,小白认真提问,还有你们说的 TPS 、QPS 分别指什么呢
    mango88
        19
    mango88  
       2022-12-07 10:59:25 +08:00
    你领导在瞎扯
    Kontinue
        20
    Kontinue  
    OP
       2022-12-07 11:06:32 +08:00
    @PlanV 阿里云的 PTS
    Kontinue
        21
    Kontinue  
    OP
       2022-12-07 11:07:39 +08:00
    @PlanV 阿里云这边,我创建的测试是最高 1000 个 RPS ,就是每秒 1000 个请求,实际 TPS 峰值是 960 ,就是最多能处理这么多
    liuhuansir
        22
    liuhuansir  
       2022-12-07 11:07:41 +08:00
    @Kontinue 我的理解 tps 的 T 指的是用户通过客户端访问,到服务端响应的整个过程,业务有简单的一次查询 mysql ,也有复杂的多次查询,甚至查询多个库,qps 的 Q 则只是单独指 mysql 的一次查询,也就是说一次 t 可能包含多个 q
    pangdundun996
        23
    pangdundun996  
       2022-12-07 11:17:03 +08:00
    @Kontinue 我理解都是指客户端请求接口到返回的过程,但 QPS 是纯查询,而 TPS 是包含增删改操作,显然用 TPS 衡量系统性能更合理,很明显这都是跟特定接口相关联的,不可能每个接口 TPS 都能到 8000 ,所以压测指标一定是根据接口逻辑不同而不同,不可能一概而定,试想一下,查询订单跟下单这两个接口能一样吗?所以你领导的要求不准确
    mango88
        24
    mango88  
       2022-12-07 11:30:34 +08:00
    可以尝试一下
    1. 把 -xms -xmx 设置成相同的固定值,避免 JVM 自动伸缩堆大小带来影响
    2. 增加一个空接口,作为基准测一下机器网络 IO
    3. 看一下 redis 的负载监控和数据库的负载,压测时候看一下机器 CPU 负载高的原因,排除一下是否因为写日志造成的磁盘 io 高
    justplaymore
        25
    justplaymore  
       2022-12-07 11:44:49 +08:00
    你的服务组成总共有三个组件:Java 应用,Redis ,MySQL 。
    思路:隔离组件测试,找瓶颈点。
    经验:大概率瓶颈点是 MySQL ,在上面的三个组件里,关系型数据库的性能是相对很低的。
    xuanbg
        26
    xuanbg  
       2022-12-07 12:19:54 +08:00
    2 台 4C ,rps8000 ?接口响应时间要在 1ms 才能做得到。其实平均 400 就已经非常不错了
    byte10
        27
    byte10  
       2022-12-07 12:34:28 +08:00   ❤️ 1
    @xuanbg 并不是的。https://www.bilibili.com/video/BV1FS4y1o7QB/ 可以看下,这里的压测说明。

    从响应时间来说,你的 java 程序起码 大概需要开到 3000 个线程才可以。所以不管你什么配置,哪怕 32 核心,100G 内存。

    首先设置足够的线程数:
    先验证是否 mysql 的瓶颈,直接 mysql 加到 16 核,看看是否有改善。如果没有的话,那么就说明瓶颈在 java 程序上,估计是 java 的代码太复杂了。

    如果瓶颈在 mysql ,要么优化 sql ,要么加配置。

    https://www.bilibili.com/video/BV1FS4y1o7QB/ 可以看下,这里的有讲解吞吐量的实际情况。

    还有你压测的 http 连接数一定要跟大于线程数,也就是你接口响应是 100ms ,那么你至少 1000 个 http 连接数才有可能达到 1w qps ,这个细节很少人知道。不解释,可以直接看视频。

    另外 java 有 jit ,必须要预热一下,才可以得到 实际上的性能,不然不准确。
    superliy
        28
    superliy  
       2022-12-07 14:07:59 +08:00
    @xuanbg 我觉得你这样考虑不准确,2 台 4C ,也就是一共 8 个核心,1ms 处理一个请求,那么 8 个核心 1ms 就是处理 8 个请求,1s=1000ms 处理 8000 个请求,你是这样算的对吗?

    那如果需要 10ms 处理一个请求,但其实 10ms 里是包含了 io 的操作的,也就是 10ms 里真正 cpu 占用的时间可能只有 1ms ,剩余的 9ms 是在等 io ,等 io 的时间 cpu 是让出资源给其他线程的,所以虽然一个请求时长 10ms ,但是 10ms 里一个核心可能也处理了 10 个请求
    Kontinue
        29
    Kontinue  
    OP
       2022-12-07 14:53:08 +08:00
    @superliy 10ms 一个请求算上网络时间了吗?
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   5457 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 33ms · UTC 02:46 · PVG 10:46 · LAX 18:46 · JFK 21:46
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.