接盘了一个项目维护，做得很闹心。 业务里面大量接口是调第三方的。 近期有人反应经常超时影响使用。
排查了下，好家伙，看日志就是调某个三方查询接口经常超时。 这个项目里用到的工具类超时时间已经设得很长了，有 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 这个能说明是哪方的问题么？ 感觉是对方处理 以及 网络都有可能。 问过三方，他们的业务也就是一个简单的查表，数据量并不大，感觉网络原因更可能。 但怎么更进一步排查呢？
Select Language