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