我在一篇博文中发现了这个问题。 Mozilla在实习面试中询问了这个问题。 （Blog Post）
您正在运行已配置的HTTP服务器（nginx，Apache等） 从现代的本地文件系统提供静态文件， 连接到千兆网络的多核服务器。少数客户 尽可能快地开始请求相同的4kb静态文件。什么 您认为系统资源会先耗尽吗？
一个。 CPU
湾磁盘/ I / O
C。内存
d。网络
即其他
据我所知，在Nginx / Apache的现代机器上，这些都不会用尽。赢得了Web服务器缓存这么小的文件并且只是继续提供服务。此外，对于重复请求，它可以轻松发送未修改的标头。
对于Apache，我想由于它通过产生线程来处理多个客户端，所以CPU将首先耗尽，但对于一个＆＃34;少数＆＃34;客户，这不重要。
我想知道别人对这个问题的看法。
答案 0 :(得分：1)
它依赖于它。 4k是这个神奇的大小，它可以在默认设置下与所有缓存和缓冲区一样好，因此传递它很容易（也很快）。内存不是限制因素，因为Web服务器将在文件句柄上操作，而不是整个文件。在这种情况下，我会假设它们在内存中保持正确，但这将是每个工作者实例的一个文件，最多通常会降至4kb * (num_cores + 1)，这不是真正的问题。
有人可能会争辩说，无论是内存还是磁盘都是一个问题。但是当正确配置sendfile之类的方法时，前者可以忽略不计，从而实现零拷贝方法。一旦文件的副本被加载到内存中，后者就会随着时间的推移而摊销。
最后，有接口和CPU。总体而言，CPU时间往往比网络时间便宜很多，所以我希望NIC在CPU之前很久就会成为瓶颈 - 如果有的话。
问题在于客户的位置有点不明确。如果它们连接到相同的GbE网络，它们确实可以使用它们的请求使NIC饱和。如果没有，一些中间人可能成为限制因素。
现在让我们假设这些客户端在我们的网络中，我们在这里有一个单宿主的10GbE网卡，通过8个通道连接（相当标准的恕我直言）：PCIe 3.0 x8指定为7,877 MB / s。 Core i7 3770的总线速度为5GT / s，在8个通道上转换为大约8 GB / s。假设没有其他I / O密集型工作负载，这个CPU可以很容易地使NIC饱和。
总结：在CPU饱和之前的网络/ NIC饱和度之前。