V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
waytodelay
V2EX  ›  程序员

调用方和被调用方,接口 TP999 差得比较远,是正常的吗?

  •  
  •   waytodelay · 23 天前 · 1094 次点击

    TP95 是差不多的,都是 15ms 左右,差个几 ms 。

    TP999 差得比较远,被调用方 100ms 不到,调用方 500ms 。

    这种情况是正常的吗?

    如果不正常那怎么排查呢?

    目前做的这个系统对时效要求比较高,请求量也比较大,超时了比较容易告警。

    16 条回复    2024-06-13 13:54:04 +08:00
    WillingXyz
        1
    WillingXyz  
       23 天前 via Android
    看下调用方的线程池,http 连接池是不是不够用,导致花时间在等待线程或连接释放
    tianshuang
        2
    tianshuang  
       23 天前
    同请求对比吧,看下时间花在哪了
    fkdtz
        3
    fkdtz  
       23 天前 via iPhone
    正常吧,tp999 基本上等于把所有请求都包括了,那存在波动很正常,至于到底哪里慢了得全链路追踪。
    waytodelay
        4
    waytodelay  
    OP
       23 天前
    @tianshuang 就是同一个请求

    @fkdtz 我看的就是单一个接口
    fkdtz
        5
    fkdtz  
       23 天前 via iPhone
    @waytodelay 我说的就是一个接口的 tp999 ,基本相当于这个接口的全部请求了。
    waytodelay
        6
    waytodelay  
    OP
       23 天前
    @fkdtz 我的意思是,我是 A ,要调 B 的 methodXXX 。
    我这边显示 methodXXX tp999 是 500ms
    B 那边显示 methodXXX tp999 是 100ms
    不涉及其他的接口啊
    waytodelay
        7
    waytodelay  
    OP
       23 天前
    @WillingXyz 这个有可能。
    liuhuan475
        8
    liuhuan475  
       23 天前
    没有 TraceId 吗
    tianshuang
        9
    tianshuang  
       23 天前
    @waytodelay 我意思是同一个 trace
    GeekGao
        10
    GeekGao  
       23 天前
    问题原因:有少部分请求因为某些原因(如资源竞争、网络延迟等)而导致响应时间显著增加。
    排查手段:
    1.日志分析:查看系统日志,看是否有错误信息或警告提示,这可能是问题的线索
    2.性能监控:使用性能监控工具(如 Prometheus 、Grafana 等)来观察系统的各项指标,如 CPU 使用率、内存消耗、磁 3.盘 IO 等,以确定是否有资源瓶颈
    3.压力测试:通过模拟高负载的情况来重现问题,并尝试找出性能下降的具体原因
    4.代码审查:检查代码中的并发控制、数据库查询优化等方面,看是否有潜在的问题
    5.依赖服务检查:如果你的系统依赖其他外部服务,检查这些服务的状态和性能,也可能是影响因素之一
    keakon
        11
    keakon  
       23 天前
    有的在 backlog 里排队,这是内核的 TCP 协议栈处理的,服务端的应用程序是不知道这个时间的,但是客户端可以感知到
    chutianyao
        12
    chutianyao  
       23 天前
    1 楼已经说出答案了, 排查下调用方的线程池.
    通常是调用方线程池满了
    fkdtz
        13
    fkdtz  
       23 天前 via iPhone
    @waytodelay 没有人说其他接口啊,我怀疑你没搞清楚 tp999 的含义。总之这种现象出现并不奇怪,从你发出请求到你接到对方的响应,这中间涉及到很多环节,存在时间差是正常的,如果出现时间差相差非常多那一定是中间环节有异常导致的,可能是线程满了在排队,可能是 gc 了,可能是网络波动,可能是系统资源不够了等等。系统方面就得结合系统的监控看是不是配置不够了,网络丢包率之类的。服务内部的话很可能是线程问题或者 gc 了,可以加链路追踪 id ,然后日志打点收集,复现的时候对比看。
    Ericcccccccc
        14
    Ericcccccccc  
       23 天前
    看看能不能细拆耗时,特别是网络那一层的。
    xueling
        15
    xueling  
       21 天前
    可能是网络层面的问题导致了小部分请求较长时间的阻塞。建议添加完整的服务监控,对整体链路、网络请求阶段、以及接口处理的每个重要环节都添加上细粒度的耗时监控。可以使用我的开源项目实现: https://github.com/xl-xueling/xl-lighthouse
    showB1
        16
    showB1  
       3 天前
    我建议你自己摸你第三方压一下,同机房、不同机房,出个标准报告。不然第三方时间慢了,他的代码咋写的、走的啥协议不都控制不了啊,这砸优化排查。你索性给个标准,让他看到“我的服务是可以做到这个性能的”,他就知道自己排查一下了。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1488 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 25ms · UTC 16:56 · PVG 00:56 · LAX 09:56 · JFK 12:56
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.