V2EX = way to explore
V2EX 是一个关于分享和探索的地方
Sign Up Now
For Existing Member Sign In
This topic created in 1928 days ago, the information mentioned may be changed or developed.
接盘了一个项目维护，做得很闹心。 业务里面大量接口是调第三方的。 近期有人反应经常超时影响使用。
排查了下，好家伙，看日志就是调某个三方查询接口经常超时。 这个项目里用到的工具类超时时间已经设得很长了，有 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 Jan 27, 2021
既然“三方这个接口，并不是稳定的慢”，那么你能做的并不是拉长超时时间，而是缩短超时时间，每次超时主动重试 N 次，都失败直接对外返回失败，让用户手动重试
|
 |
2
seanxx Jan 27, 2021
出口抓包看吧,看哪两个点之间慢
|
 |
3
mitsuizzz Jan 27, 2021
是对接的第三方吗 找他们要说法呀，之前对接过一个跨境电商的第三方，好家伙，过年那几天服务器升级维护没告诉我们， 那几天的单子全没收到，还好我们有手动推送
|
 |
5
livesitter Jan 27, 2021
对方应该要对接口稳定性作保障吧
|
 |
6
exmario Jan 27, 2021
内网测试 /让对方写收到请求和发送响应完成的 log
|
 |
7
Rache1 Jan 28, 2021
如果是使用的域名访问，对方有固定 IP 的话，可以考虑编辑 hosts 减少 dns 的消耗。
另外如一楼说的，加上主动超时，不然锅全是你自己的 |
Select Language