apache / apache/servicecomb-java-chassis

微服务调用耗时问题咨询

未关闭
#3,523 5 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看
主要语言
Java
星标
1.9k
派生
814
平均合并
8 天 23 小时
30 天内合并 PR
1

描述

调用过程nlsb -> edge (服务A) -> provider(服务B),存在部分(万分之几十) provider 响应只有10ms, 但是edge响应时间800ms左右的请求。edge本身几乎没有处理业务。 类似日志如下
调用时间:2022-12-13 16:24:46.975
一、edge日志:
1. 调用日志
**2022-12-13 16:24:46.975**|transport-vert.x-eventloop-thread-1|DEBUG|LoadBalancerContext.java:getServerFromLoadBalancer:492|c225268d-1e24-4a93-b579-8c15eaa8ae7c|default using LB returned Server: rest://182.10.xx.xxx:8080?sslEnabled=true for request null
2. access.log
2022-12-13 16:24:46.973|182.10.xxx.0=xx|"POST /rtd/kbz_fraud_prevention/kbz_fraud_prevention/P2P_Verify/1.0/verify HTTP/1.1"|200|c225268d-1e24-4a93-b579-8c15eaa8ae7c|**823**

二、provider日志access.log
**2022-12-13 16:24:46.976**|182.10.xx.xxx|"POST /risk-api/v1/kbz_fraud_prevention/P2P_Verify/predict HTTP/1.1"|200|c225268d-1e24-4a93-b579-8c15eaa8ae7c|**10**

edge的CPU及内存使用都不足50%
可能是什么原因导致的呢?

贡献指南

这个仓库没有索引到贡献指南

调研方向

首先比较 edge 和 provider 访问日志中的时间戳与请求 ID,然后检查 getServerFromLoadBalancer 附近的 LoadBalancerContext.java。使用现有日志跟踪 provider 响应到 edge 完成之间的时间间隔。完成的标准是记录已确认的延迟差距原因及支持该原因的证据。

由索引模型根据 Issue 内容生成。

评估

技术栈
java
领域
backend, distributed-systems
Issue 类型
缺陷
难度
4/5
预计耗时
3-5 天
活跃度
停滞
描述清晰度
需要澄清
新手友好度
25/100

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。