我一直在尝试解决一些随机延迟问题，这种延迟发生在我向服务器发送的请求中，不到 3%。我编写了一个测试脚本，该脚本在单独的服务器上使用 PHP 的 file_get_contents，并在各处使用时间戳来计时处理时间。我在服务端测试了静态 HTML 和 PHP 文件，结果都是同样的随机延迟。
我的问题是，随机检索一个静态页面应该需要 0.1 秒，但检索却需要 3 秒，有时甚至需要 5 秒。极少数情况下，它需要 2 秒或 4 秒。
我调查了下面列出的各种问题，但似乎无法确定问题所在。通过时间戳，我发现延迟发生在 apache 提供文件之前。apache 日志中的时间戳与文件的开始时间相匹配，并且非常接近我将文件返回到测试脚本的时间。
我的测试脚本同时向测试页面发送 5 个请求，然后在处理完该命令后再启动 5 个请求。
滞后的服务器在脚本运行时没有异常负载。CPU 低于 10%，内存始终至少有 1 GB 可用。滞后的负载百分比可以通过增加同时连接数来增加。在扩展测试期间，偶尔会有页面完全丢失。我测试了 100 万个页面，只有 10 个页面丢失。
我无法禁用的唯一防火墙是路由器中的防火墙。这是一款相当不错的路由器，内置了一些 DOS 攻击预防措施。来自同一 IP 的大量请求是否可能触发 DOS 协议，而路由器会阻止请求？
任何建议或值得关注的事情都将不胜感激。下面列出了我的结论和评论。
1) DNS 查找没有发生。我使用 netstat 进行观察以确认这一点。2) 服务器资源没有用完。3) 测试脚本与滞后服务器位于不同的服务器和网络上。4) 防火墙不应该是问题。禁用防火墙也会出现相同的结果。5
) 我尝试过增加最大客户端数和其他设置的 apache 配置。但都无法解决这个问题。如果有人遇到过这个问题并且知道有用的配置，我很乐意尝试。6) 我测试了 keep-alive 的开启和关闭，没有明显的区别。7) 我测试了两个 apache MPM，出现了相同的滞后。8) apache 日志文件 %D 值显示，对于需要 0.1 秒才能提供服务的页面和需要 3 秒才能加载的页面，没有增加。
我很难相信互联网上没有人遇到过这个问题，但我已经连续搜索了 3 天，却找不到解决方案。任何帮助都将不胜感激。谢谢。
答案1
除了测试脚本之外，还可以尝试运行基准测试应用程序，例如 ApacheBench (ab) 或 Siege。还可以在本地服务器上运行此应用程序和测试脚本。如果是路由器/网络问题，则本地服务器上的测试应该不会显示任何问题。您可以尝试 ab/siege 的并发请求，看看问题是否在更高的并发性下发生得更多。使用各种文件和文件类型进行测试，看看是否有任何不同。
大多数故障排除的关键是复制问题，然后缩小原因范围。由于您将其描述为“随机”，因此我会尝试专注于尽可能可靠地复制问题。如果您无法复制问题，那么您最终将无法真正知道您是否真正解决了问题。
事实上，情况可能是“互联网上没有人遇到过此问题”。实际上，有无数的硬件/软件/应用程序配置使得诊断此类问题变得困难。人们也可能对同一问题使用不同的描述：您所说的“随机 Apache 延迟”可能被其他人称为“远程以太网性能问题”。