技术解析

服务器距离很近,但是调用服务时间很长是什么原因?
0
2021-05-13 22:35:38
idczone

由于公司的业务要求,我们需要让两个项目调用同一个服务,服务通过 HTTP 传输,具体情况是这样的: 项目 A 和项目 B ,同时需要调国外服务器用 S 服务,其中 A 和 S 位于同一个局域网中, B 是另外的一个局域网,之前 B 是联通托管, A 和 S 都是电信托管,后由于 B 访问 S 时间过长,把 S 的服务映射到了联通的 IP 地址。 映射之后到现在, B ping S 的地址只需要不到 1ms 。 但是, A 调用 S 的时候只需要 4~5ms 返回结果,但是 B 调用 S 就需要 100+ms ,有时候甚至到了 200ms 。 不知道是什么原因,会不会是 IP 地址映射的问题?


世界最远的距离……

说真的,楼主,你在发这个帖子之前有没有试过一条神奇的命令叫 ping ?

具体场景具体排查,在帖中楼主提到 B 到 S 的 ping 延迟是 1ms ,那么至少证明 ICMP 通路的路由是正常的。
建议试试 TCP PING 直接对服务接口进行检查,看延迟值是否在可接受范围内。
以此排除由路由配置导致的数据包走向异常。

我错了。楼主 Ping 过。
这样就进入了很“脏”的排查阶段了。首先是写一个 TCP Echo 服务器,部署在 S 上,然后让 B 调用这个 Echo 服务器看看延迟是什么样的,这样能排查是否是服务器上的应用程序或 iptables 这样防火墙导致的问题。
然后检查通过路由的 QoS 之类设置,看是不是 QoS 对数据请求设置了优先级。

这 TM 就叫咫尺天涯。

我去试试

现在 A 调用 S 的时间只有 4~5ms ,这样能够排除应用程序的问题吗?


不能排除没有,比如你后端程序对两个 IP 地址来源有不同的处理策略之类,或者 iptables 有特殊的配置。


其实你可以做另一个测试,放另一台机器 C 在 B 的子网里,然后从 A 的子网的一台机器 D 访问 C (用 TCP Ping 之类),如果问题复现了,你需要检查 A<->B 网络中间的路由,看是否有比如 QoS 策略、防火墙之类导致了这些延迟。
如果问题没有复现,则可能问题很大可能是出在 B 和 A 这两台机器本身的程序上。

linux:tracerout
windows:tracert

数据地带为您的网站提供全球顶级IDC资源
在线咨询
专属客服