我们有一台四核 i7、8G 的机器，连接着千兆网络。有 4 个 WiFi 接入点，我们将 50 台 iPad 连接到这些接入点，这些 iPad 有一个应用程序可以从服务器下载文件。
该服务器正在运行 NGINX，其位置位于服务器上的一个文件夹中。该文件夹中有一个 190MB 大小的文件。
我们测试了 3 台 iPad。下载耗时约 1 分 10 秒，即 2.7Mbps。
然后，我们尽可能同时在 50 台 iPad 上开始下载文件。
我们看到 20 台 iPad 失败，30 台成功。在 NGINX 访问日志中，我们看到 30 台 200 OK，其完整字节数为 190MB，20 台字节数在 80MB 左右。
在测试期间，我处于最高运行状态。我注意到 eth0 任何时候都不超过 6%。CPU 使用率 < 1%，RAM 有 5GB 空闲，没有变化。NGINX 进程有时位于进程列表的顶部，但大多数时候不在。按 RAM 排序，然后是 CPU。si 的最高值为 1900K，速度也是 90Mbps。
我不知道如何调试这个问题。我们的网络团队今天会来，但我想告诉他们一些有用的信息。理想情况下 - 这不是服务器的问题。根据上面的读数，我认为这不是服务器的问题。如果能有其他方法调试这种问题，访问日志会清楚地显示客户端未完成下载，我将不胜感激。
如果失败的请求达到 80MB，那么它们与成功请求的连接和下载就不会出现问题，对吗？80MB 左右的请求中断了？有趣的是，许多失败请求的请求大小都差不多（有些则不同）。这是否意味着网络故障？服务器本身是否可能出于某种原因决定不再继续满足现有连接？
谢谢
答案1
这很可能是由于同时进行如此多的无线下载造成的。我要做的第一件事就是再次尝试 20 次失败的下载，在此期间，我会跳转到 AP 并检查其日志或日志缓冲区以查看是否有任何线索。
不过，一般来说，无线下载会中断和/或失败，因此我建议不要花费大量时间来解决无线下载问题，除非这种情况发生的频率足以表明您的环境或网络存在问题。