ページがサーバー側で生成されているときはいつでも、データベースは常にテントの長い柱であるというマントラを知っています。
しかし、Web サーバー上でかなりの量のファイル I/O が行われています。スクリプト化されたコードは、include/require ステートメントでいっぱいです。さらに、通常、テンプレート化された html をアプリケーションの外部のファイルに格納し、それに応じてロードして入力することを実践します。
Web 開発に関係する場合、ファイル I/O はどの程度の役割を果たしますか? それが問題になることはありますか？多すぎるのはいつですか？Web サーバー/言語は何かをキャッシュしますか?
あなたの経験でそれが本当に重要だったことはありますか？
10 年前、ディスクはプロセッサよりもはるかに高速だったので、それほど気にする必要はありませんでした。ディスクが問題になる前に、CPU が不足する (または NIC が飽和状態になる) でしょう。最近では、CPU とギガビット NIC がディスクをボトルネックにする可能性がありますが....
ほとんどの非データベース ディスクの使用は、非常に簡単に並列化できます。システムを追加して水平方向に拡張するようにホスティング アーキテクチャを設計していない場合は、ディスク アクセスを微調整するよりも、その方が重要です。
水平方向に拡張するように設計されている場合、通常、サーバーを追加購入するだけで、ディスクを最適化する方法を考え出すよりも安価になります。言うまでもなく、テンプレート用の SSD や RAM ディスクでさえ、問題にはなりません。
水平方向にスケーリングし、スケーラビリティの問題を引き起こすほど人気がありますが、ラックにさらに 1u を追加できるほど収益性が高くないサービング アーキテクチャを持つことは非常にまれです。
ファイル I/O は、外部への帯域幅がディスク帯域幅と同程度である場合にのみ (静的コンテンツおよび静的ページ インクルードの場合) 要因になります。これは、接続が非常に高速であるか、高速な LAN でコンテンツを提供しているか、ディスクが非常に遅い (またはディスクの競合が多い) ことを意味します。したがって、ほとんどの場合、答えはノーです。
もちろん、これは、ファイルの小さな部分に対してのみ大きなファイルをロードしていないことを前提としています。
時期尚早に最適化しないでください。その悪、または何か。
ただし、I / Oは、コンピューターで実行できる最も遅い処理です。最小限に抑えるようにしてください。ただし、Knuthに自分が何をしているかを見せないでください。
ファイル I/O は、帯域幅、ネットワーク接続、メモリなど、Web アプリケーションのパフォーマンスに影響を与える可能性のある多くの要因の 1 つです。ファイル I/O が問題を引き起こしているかどうかを判断する最も効果的な方法は、サーバーでプロファイリングを実行し、これがパフォーマンスの境界要因であるかどうかを確認することです。
これの多くは、ディスクからロードするファイルの種類によって異なります。多くの小さなファイルは、いくつかの大きなファイルとは非常に異なるプロパティを持っています。Web サーバーはファイルを内部的にメモリにキャッシュすることができ、ファイル (画像など) をキャッシュできるため毎回要求する必要がないことをクライアントに示すことができます。
大量の静的コンテンツを提供している場合にのみ、ファイル IO 速度が問題になると思います。データを処理し、コードを実行してページをレンダリングする場合、ディスクからページ自体を読み取る時間はごくわずかです。ファイル I/O は、ビデオや画像ファイルを提供している場合など、提供している静的ファイルがメモリに収まらない場合に重要です。html ファイルでも発生する可能性がありますが、html ファイルではサイズが非常に小さいため、発生する可能性は低くなります。