我知道的口头禅是，无论何时在服务器端生成页面，数据库始终是帐篷里的长杆。

但是，Web服务器上也有大量的文件I / O。脚本代码充满了include / require语句。而且，通常的做法是在应用程序外部将模板化的html存储在相应地加载和填充的文件中。

在进行Web开发时，文件I / O扮演什么角色？它曾经成为一个问题吗？什么时候太多？ Web服务器/语言是否缓存任何内容？

在经历中，它真的很重要吗？

解决方案

我要说的是，文件IO速度仅在我们要提供大量静态内容时才成为问题。当我们处理数据并执行代码以呈现页面时，从磁盘读取页面本身的时间可以忽略不计。在我们要提供的静态文件无法放入内存的情况下(例如，当我们提供视频或者图像文件时)，文件I / O非常重要。 html文件也可能发生这种情况，但是由于html文件的大小非常小，因此可能性较小。

10年前，磁盘比处理器快得多，因此我们不必太担心它。在磁盘成为问题之前，我们会用完CPU(或者使NIC饱和)。如今，CPU和千兆网卡可能使磁盘成为瓶颈，但...。

大多数非数据库磁盘的使用非常容易并行化。如果我们尚未通过添加更多系统来设计主机架构来横向扩展，那么这比微调磁盘访问更为重要。

如果我们打算横向扩展，通常购买更多服务器要比尝试找出如何优化磁盘便宜。更不用说，诸如SSD之类的东西甚至是模板的RAM磁盘，都将使它成为非问题。

具有水平扩展的服务架构的情况非常罕见，这种服务架构流行到足以引起可伸缩性问题，但利润却不足以在机架中提供另外的1u。

如果外部带宽与磁盘带宽相似，则文件I / O仅会成为一个因素(对于静态内容和静态页面而言)。这意味着我们连接速度非常快，正在快速的LAN上提供内容，或者磁盘速度很慢(或者存在大量磁盘争用)。因此，最有可能的答案是"否"。

当然，这假设我们不是仅为文件的一小部分加载大文件。

文件I / O是许多因素之一，包括带宽，网络连接性，内存等，这些因素可能会影响Web应用程序的性能。确定文件I / O是否导致我们出现任何问题的最有效方法是在服务器上运行一些性能分析，并查看这是否代表性能受到限制。

这在很大程度上取决于我们要从磁盘加载的文件类型，许多小文件与一些大文件的属性将有很大不同。 Web服务器可以在内存内部缓存文件，并且可以向客户端指示可以缓存文件(例如图像)，因此不需要每次都请求。

不要过早优化。它是邪恶的，还是什么。

但是，I / O是我们在计算机上执行的最慢的操作。尝试将其保持在最低水平，但不要让Knuth看到我们在做什么。