まず、Nathanel Jones ブログへの参照リンクに関して、ディスク IO はメモリ操作よりもはるかに遅いですが、ほとんどの Web サイトはディスク IO バウンドではなく、彼のソリューションのほとんどは率直に言って無知ながらくたです。
一般的に言えば、DISK io バウンドになる状況はごくわずかです。1 つ目は、データベース サーバー自体です。データベースの関連部分をメモリに保持するのに十分なRAMがない場合、そのサーバーのディスク速度が重要です。特にトランザクションの多い状況では。
次に、アプリケーションが大量のファイルを直接読み書きする場合、ディスク IO バウンドになる可能性があります。これを行うアプリはほとんどありません。アプリケーションの .aspx または .html ファイルはカウントしていません。これらは既存のフレームワークと IIS によってキャッシュされる可能性があるためです。
基本的に、彼を無視してください。
パフォーマンスを改善する方法としてのファイルシステム全体からデータベースへの同期のアイデアは、約 99.999% のサイトにとって価値がありません。他に何もない場合、データベースはファイルを Web サーバーのファイル システムにプッシュするべきであり、その逆ではありません。20 年間の開発で、これを必要とするサイトを 1 つだけ見たことがあります。1 日に数百万ページビューを提供しています。また、ローカル ファイルから同等の量のデータをロードするよりも、ネットワーク経由でデータベース呼び出しを行う方が高速であるという点についても、彼は完全に間違っています。
次に、私たちが実際に縛られている領域は、ネットワークを介してクライアント ブラウザにデータを送信することです。これは、ディスクからファイルを読み取るよりも常に遅くなります。回線にトラフィックがなくても。ハード ドライブは、ネットワーク カードよりもはるかに高速にデータを移動します。それをさらに一歩進めます。最新のハード ドライブは、インターネット接続よりも桁違いに高速です。パフォーマンスを改善するためにできる最善の方法は、1 つのページの読み込みに必要な接続要求の数を制限することです。ここでの最適化とは、20 個ではなく 1 個の css ファイルを持つことを意味します。100 ではなく、2、3 の .js ファイル参照しかありません。可能な場合は、グラフィックをスプライトに結合します。TCP の仕組みにより、100 個の小さなファイルを転送するよりも、1 つの大きなファイルを転送する方が高速です。
過負荷の共有サーバーで問題が発生する可能性があります。ただし、実際には、共有サーバーが過負荷になると、ディスク キューの長さが制御不能になるずっと前に、ネットワークが混雑します。
それでは、実際の問題を見てみましょう。
JavaScript アイテムには 2 つの推奨される場所があります: 1. Web サーバー上の .js ファイルとして、または 2. マスター ページに埋め込まれます。オプション 1 を実行するだけで、Web サーバーによってキャッシュされます。さらに、それらはクライアント ブラウザによってキャッシュされるため、キャッシュする必要はありません。
ヘッダーとフッターの場合、このコードはマスター ページにある必要があります。サーバー側のインクルードを行わないでください。複雑になるだけです。「クロム」コンテンツのマスター ページを活用する通常の .net Web サイトを構築します。すべてのキャッシュを処理するアプリケーション レベルで部分的なページ キャッシュを有効にすることができます。
ヘッダーまたはフッターのコンテンツを更新したら、サイトを再デプロイするだけです。