微服务调用耗时问题咨询

调用过程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%
可能是什么原因导致的呢？

Commencez par comparer les horodatages et l’ID de requête dans les journaux d’accès edge et provider, puis examinez LoadBalancerContext.java autour de getServerFromLoadBalancer. Retracez l’intervalle entre la réponse du provider et la fin du traitement sur edge à l’aide des journaux existants. La tâche est considérée comme terminée lorsqu’une cause confirmée de l’écart de latence ainsi que les éléments qui l’étayent sont documentés.

Rédigé par le modèle d'indexation à partir du texte de l'issue.