0

我们正在使用 websockets(特别是 Node.js 上的 uws.js)来运行多人测验。该服务器在 eu-west-2a 区域的 AWS t2.micro 上运行,但最近,我们看到一些玩家的延迟非常高 - 但只是间歇性的。

通过延迟,我实际测量的是从发送广播消息(使用 uws 内置的 pub-sub)到玩家设备告诉服务器他们已经安全接收到它所花费的时间。我们正在跟踪的消息告诉玩家的设备进入下一阶段的测验,因此它对应用程序的工作非常关键。大多数时候,对于英国的玩家来说,这个时间大约是 30 到 60 毫秒,但时不时地我们会看到长达 17 秒的延迟。

最近我们在世界的另一端有一个小组到我们的服务器做一个测验,虽然只有十来位玩家,所以服务器绝对没有超载,我们看到大约一半的小组断断续续地得到这些,非常高的延迟峰值,他们的设备需要 12、17、22 甚至 39(!!) 秒才能确认已收到消息。尽管这是一个慢节奏的测验,但这仍然是一个令人难以置信的延迟,并且会产生真正的不利影响。

我的问题是,我怎么知道是什么原因造成的,我该如何解决?我的猜测是这与 TCP 及其按顺序交付有关,再加上一些可能不可靠的互联网连接,因为昨天的一名玩家似乎在 39 秒内什么也没收到,然后连续三条消息都被备份了。对我来说,这表明丢包,但在尝试解决它时我什至不知道从哪里开始。我还没有弄清楚如何重现它(我在玩自己的时候从未见过它发生过),这让事情变得更加困难。

4

1 回答 1

0

TCP 路由问题不太可能导致 17 秒以上的极端延迟。您确定没有“存储和转发”队列系统在服务器或云发布/订阅队列上缓冲您的消息吗?

另一个重要检查:t2.micro 几乎是您可以在 AWS 上启动的最便宜、最不可靠的网络 QoS VM。对网络性能没有吞吐量和抖动保证。您不妨回顾一下:

  1. AWS 的 EC2 网络基准测试指南,包括 MTU 参数
  2. EC2 的可用实例带宽

例如,t2.micro 没有任何最低基线保证带宽。

于 2021-10-27T22:23:05.143 回答