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

[waytodelay]

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

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

这种情况是正常的吗？

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

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

[WillingXyz]

看下调用方的线程池，http 连接池是不是不够用，导致花时间在等待线程或连接释放

[tianshuang]

同请求对比吧，看下时间花在哪了

[fkdtz]

正常吧，tp999 基本上等于把所有请求都包括了，那存在波动很正常，至于到底哪里慢了得全链路追踪。

[waytodelay]

@tianshuang 就是同一个请求

@fkdtz 我看的就是单一个接口

[fkdtz]

@waytodelay 我说的就是一个接口的 tp999 ，基本相当于这个接口的全部请求了。

[waytodelay]

@fkdtz 我的意思是，我是 A ，要调 B 的 methodXXX 。
我这边显示 methodXXX tp999 是 500ms
B 那边显示 methodXXX tp999 是 100ms
不涉及其他的接口啊

[waytodelay]

@WillingXyz 这个有可能。

[liuhuan475]

没有 TraceId 吗

[tianshuang]

@waytodelay 我意思是同一个 trace

[GeekGao]

问题原因：有少部分请求因为某些原因（如资源竞争、网络延迟等）而导致响应时间显著增加。
排查手段：
1.日志分析：查看系统日志，看是否有错误信息或警告提示，这可能是问题的线索
2.性能监控：使用性能监控工具（如 Prometheus 、Grafana 等）来观察系统的各项指标，如 CPU 使用率、内存消耗、磁 3.盘 IO 等，以确定是否有资源瓶颈
3.压力测试：通过模拟高负载的情况来重现问题，并尝试找出性能下降的具体原因
4.代码审查：检查代码中的并发控制、数据库查询优化等方面，看是否有潜在的问题
5.依赖服务检查：如果你的系统依赖其他外部服务，检查这些服务的状态和性能，也可能是影响因素之一

[keakon]

有的在 backlog 里排队，这是内核的 TCP 协议栈处理的，服务端的应用程序是不知道这个时间的，但是客户端可以感知到

[chutianyao]

1 楼已经说出答案了, 排查下调用方的线程池.
通常是调用方线程池满了

[fkdtz]

@waytodelay 没有人说其他接口啊，我怀疑你没搞清楚 tp999 的含义。总之这种现象出现并不奇怪，从你发出请求到你接到对方的响应，这中间涉及到很多环节，存在时间差是正常的，如果出现时间差相差非常多那一定是中间环节有异常导致的，可能是线程满了在排队，可能是 gc 了，可能是网络波动，可能是系统资源不够了等等。系统方面就得结合系统的监控看是不是配置不够了，网络丢包率之类的。服务内部的话很可能是线程问题或者 gc 了，可以加链路追踪 id ，然后日志打点收集，复现的时候对比看。

[Ericcccccccc]

看看能不能细拆耗时，特别是网络那一层的。

[xueling]

可能是网络层面的问题导致了小部分请求较长时间的阻塞。建议添加完整的服务监控，对整体链路、网络请求阶段、以及接口处理的每个重要环节都添加上细粒度的耗时监控。可以使用我的开源项目实现： https://github.com/xl-xueling/xl-lighthouse

[showB1]

我建议你自己摸你第三方压一下，同机房、不同机房，出个标准报告。不然第三方时间慢了，他的代码咋写的、走的啥协议不都控制不了啊，这砸优化排查。你索性给个标准，让他看到“我的服务是可以做到这个性能的”，他就知道自己排查一下了。