apache / apache/servicecomb-java-chassis
微服务调用耗时问题咨询
- 主要言語
- Java
- スター
- 1.9k
- フォーク
- 814
- 平均マージ
- 8日 23時間
- マージ済み PR(30日)
- 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