调三方接口，时不时会有超时严重的现象？有哪些排查的点？

[chillingkitten]

接盘了一个项目维护，做得很闹心。 业务里面大量接口是调第三方的。 近期有人反应经常超时影响使用。
排查了下，好家伙，看日志就是调某个三方查询接口经常超时。 这个项目里用到的工具类超时时间已经设得很长了，有 10 秒，直接把参数拷出来在 postman 里直接调，居然有几十秒才返回的情况。 说实话 10 秒都不返回，在今天的互联网早都是不可接受的了。 所幸这个应用的流量不大，还暂时不用考虑什么句柄耗尽拖垮服务的问题。

关键是，三方这个接口，并不是稳定的慢，大多数情况下也是 1 秒内就返回了。 对方当然说是网络原因，现在不懂技术的产品项目经理这些又找我要说法,我也比较无语。

我用 curl -s -w 命令在服务器上调，打印出来的结果举个例吧
time_namelookup: 0.000
time_connect: 0.027
time_appconnect: 0.000
time_pretransfer: 0.032
time_starttransfer: 18.730
time_redirect: 0.000
time_total: 18.730

time_starttransfer: 18.730 这个能说明是哪方的问题么？ 感觉是对方处理 以及 网络都有可能。 问过三方，他们的业务也就是一个简单的查表，数据量并不大，感觉网络原因更可能。 但怎么更进一步排查呢？

[opengps]

既然“三方这个接口，并不是稳定的慢”，那么你能做的并不是拉长超时时间，而是缩短超时时间，每次超时主动重试 N 次，都失败直接对外返回失败，让用户手动重试

[seanxx]

出口抓包看吧,看哪两个点之间慢

[mitsuizzz]

是对接的第三方吗 找他们要说法呀，之前对接过一个跨境电商的第三方，好家伙，过年那几天服务器升级维护没告诉我们， 那几天的单子全没收到，还好我们有手动推送

[chmaple]

@opengps 同意
可以先在己方环境对接口耗时做一个统计，得到一个正常情况的范围和一些零散会超时的情况的接口耗时数据
然后添加或缩短本地接口超时的限制

[livesitter]

对方应该要对接口稳定性作保障吧

[exmario]

内网测试 /让对方写收到请求和发送响应完成的 log

[Rache1]

如果是使用的域名访问，对方有固定 IP 的话，可以考虑编辑 hosts 减少 dns 的消耗。

另外如一楼说的，加上主动超时，不然锅全是你自己的