为什么这个http对话有10秒的延迟？

Question

我有一个奇怪的情况。我第一次在10.1.10.29点击嵌入式Web服务器（uclinux / boa）时，在事情开始发生之前，我在浏览器窗口中得到了10秒的延迟。 “第一次”意味着我几天没有打机。浏览器类型/操作系统无关紧要（源代码为10.1.10.20）

我有一个Wirehark捕获它正在发生。

以下是第296帧的细节：

注意，在296之后，数据包374不会弹出大约10秒。这些数据包之间的数据包不是来自有问题的机器。它只是坐在那里10秒钟并决定重新传输。它应该如何运作？

Answer 1

主要原因当然是因为代码已从内存中换出。

MS-Windows在这方面非常糟糕。如果某些程序没有被“太长时间”使用，它就会被换掉内存。期。当你回来时，它必须从硬盘重新读回来。

一件好事（主要原因）Windows就是对内核内存进行碎片整理。为此，这很好。

但是，只有当您的服务器需要内存时，您在Linux下才会遇到类似的问题。换句话说，如果你有大量的进程并且它们都争夺尽可能多的内存，那么它很可能会换掉最少使用的软件。否则它会留在原地。

如果您要使用Cassandra数据库系统，您会注意到任何运行Cassandra之外的计算机。如果你只是运行Cassandra，它一直都很快。如果您运行其他使用大量内存的软件，Cassandra首次访问速度很慢。这一点尤为明显。

Answer 2

我想添加解决我们的问题的答案，该问题出现了10秒的延迟，然后开始工作，并且在闲置5分钟后又增加了10秒的延迟。

首先，我们对所有内容进行了有线通信，并尝试在代码中或者计算机或服务器处理网络流量的方式中发现某种错误。没有发现异常。

经过大量搜索，我们发现这是一个DNS-“问题”。在客户端计算机使用的DNS服务器中，有两个用于服务器域名的条目。一个是正​​确的，一个（列表中的第一个）是错误的。

因此删除错误的dns指针即可解决问题。

这意味着问题是计算机尝试了它获得的第一个地址，等待10秒以得到答复，但没有得到它，然后转到了第二个地址。这不会产生任何错误消息，因为这应该是DNS的工作方式。这就是为什么我们所有的Wireshark日志都显示为仅等待10秒钟而没有任何错误且没有任何原因，然后立即生效，只要DNS记录有效（在我们的情况下为5分钟），然后执行该步骤需要再次做。

希望这对遇到类似问题的人有所帮助。