这是一个创建于 1432 天前的主题，其中的信息可能已经有所发展或是发生改变。
接盘了一个项目维护，做得很闹心。 业务里面大量接口是调第三方的。 近期有人反应经常超时影响使用。
排查了下，好家伙，看日志就是调某个三方查询接口经常超时。 这个项目里用到的工具类超时时间已经设得很长了，有 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 这个能说明是哪方的问题么？ 感觉是对方处理 以及 网络都有可能。 问过三方，他们的业务也就是一个简单的查表，数据量并不大，感觉网络原因更可能。 但怎么更进一步排查呢？
排查了下，好家伙，看日志就是调某个三方查询接口经常超时。 这个项目里用到的工具类超时时间已经设得很长了，有 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 这个能说明是哪方的问题么？ 感觉是对方处理 以及 网络都有可能。 问过三方，他们的业务也就是一个简单的查表，数据量并不大，感觉网络原因更可能。 但怎么更进一步排查呢？
 |
1
opengps 2021-01-27 11:22:57 +08:00
既然“三方这个接口，并不是稳定的慢”，那么你能做的并不是拉长超时时间，而是缩短超时时间，每次超时主动重试 N 次，都失败直接对外返回失败，让用户手动重试
|
 |
2
seanxx 2021-01-27 14:36:22 +08:00
出口抓包看吧,看哪两个点之间慢
|
 |
3
mitsuizzz 2021-01-27 14:59:47 +08:00
是对接的第三方吗 找他们要说法呀，之前对接过一个跨境电商的第三方，好家伙，过年那几天服务器升级维护没告诉我们， 那几天的单子全没收到，还好我们有手动推送
|
 |
4
chmaple 2021-01-27 15:13:09 +08:00
|
 |
5
livesitter 2021-01-27 16:35:24 +08:00
对方应该要对接口稳定性作保障吧
|
 |
6
exmario 2021-01-27 16:44:38 +08:00
内网测试 /让对方写收到请求和发送响应完成的 log
|
 |
7
Rache1 2021-01-28 09:37:36 +08:00
如果是使用的域名访问，对方有固定 IP 的话，可以考虑编辑 hosts 减少 dns 的消耗。
另外如一楼说的，加上主动超时，不然锅全是你自己的 |
Select Language