我在一篇博文中遇到了这个问题。 Mozilla 在他们的实习面试中问到这个问题。 ( Blog Post )
You are running a HTTP server (nginx, Apache, etc) that is configured to serve static files off the local filesystem of your modern, multi-core server connected to a gigabit network. A handful of clients start requesting the same 4kb static file as fast as they can. What system resource do you think will be exhausted first?
a. CPU
b. Disk / I/O
c. Memory
d. Network
e. Other
在我看来，在使用 Nginx/Apache 的现代机器上，这一切都不会耗尽。网络服务器不会缓存这么小的文件并继续提供服务吗？此外，对于重复请求，它可以轻松发送 Not-Modified header 。
在 Apache 的情况下，我猜由于它通过生成线程处理多个客户端，CPU 将首先耗尽，但对于“少数”客户端，这无关紧要。
我想知道其他人对这个问题有何看法。
最佳答案
这真的取决于。 4k 是一种神奇的大小，可以与所有默认设置下的缓存和缓冲区一样好，因此可以轻松(快速)传递。内存不是这里的限制因素，因为网络服务器将在文件句柄上运行，而不是整个文件。在这种情况下，我会假设他们将其保存在内存中，但这将是每个工作实例一个文件，通常最多可以减少到 4kb * (num_cores + 1)，这并不是一个真正的问题。
有人可能会争辩说内存或磁盘速度是一个问题。但是当像 sendfile 这样的方法时，前一个可以忽略不计。正确配置，支持零拷贝方法。一旦文件的副本加载到内存中，后者将随着时间的推移而摊销。
最后是接口(interface)和 CPU。总的来说，CPU 时间往往比网络时间便宜很多，所以我预计 NIC 会在 CPU 之前成为瓶颈 - 如果有的话。
这个问题对于客户的位置有点不明确。如果他们连接到同一个 GbE 网络，他们确实有能力用他们的请求使您的 NIC 饱和。否则，某些中介可能成为限制因素。
现在让我们假设这些客户端在我们的网络中，并且我们这里有一个单宿主 10GbE NIC，通过 8 channel 连接(恕我直言，这是相当标准的):PCIe 3.0 x8 指定为 7,877 MB/s。 Core i7 3770具有 5GT/s 的总线速度，在 8 条车道上相当于大约 8 GB/s。假设没有其他 I/O 密集型工作负载，此 CPU 很容易使 NIC 饱和。
总而言之:网络/NIC 饱和先于 CPU 饱和。
关于apache - 静态 Web 服务器的资源使用情况，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/37000991/