ASP.NET MVCプロジェクトに取り組んでおり、キャッシュ戦略の検討を開始したいと思うようになりました。キャッシングで使用できるように、フレームワークを可能な限り開いたままにしようとしました。
Scott Hanselmanのポッドキャストで聞いたところによると、StackOverflow.comはページ出力キャッシュを使用し、そのコンテンツを圧縮してRAMに入れます。これは、ユーザー全体のキャッシュには最適のように聞こえますが、パーソナライズされたページのようなものでは、ユーザーごとにバージョンをキャッシュする必要があり、すぐに制御できなくなる可能性があります。
したがって、キャッシング戦略の場合。出力キャッシング、データキャッシング、または組み合わせて使用する必要がありますか？私の最初の考えは両方ですが、キャッシュの依存関係に関しては、少し複雑になる可能性があるように思われます。
大規模 (1 日 300 万回の訪問) の Web サイト (ニュース ポータル) で API と出力のキャッシュを行っています。サイトは主に匿名ユーザーによって使用されますが、認証されたユーザーがいて、サイトの一部のパーソナライズされた部分のために完全なサイトをキャッシュしています.
したがって、私のアドバイスは、API キャッシュにできることはすべてキャッシュして、出力キャッシュの再構築がさらに高速になるようにすることです。
もちろん、パフォーマンス カウンターのキャッシュ比率の値には細心の注意を払ってください。キャッシュされたヒットの 95% を超える数値が表示されるはずです。
もう 1 つ注意すべきことは、キャッシュの無効化です。これは、関連するコンテンツが多数ある場合に大きな問題となります。たとえば、音楽をキャッシュすると、1 つのアルバムまたは曲に関する情報が表示され、数百ページにキャッシュされる場合があります。その曲に何か変更があった場合、これらのページをすべて無効にする必要があり、問題が発生する可能性があります。
要するに、キャッシングは ASP.NET の最高の機能の 1 つであり、優れた機能を備えており、信頼できます。
過度にアグレッシブなキャッシングに注意してください。キャッシュはパフォーマンスを向上させるためのツールですが、誤って使用すると、実際にはパフォーマンスが低下する可能性があります。
プロジェクトの詳細を知らなければ、出力キャッシングとデータキャッシングのどちらがうまく機能するかについては答えられません。いつ使用するかについて、いくつか例を挙げて説明します。
多くの異なるビューで頻繁に使用する特定のデータセットがある場合は、データキャッシュを使用することをお勧めします。データフェッチ操作が非常に一般的で、データレンダリングに比べて費用がかかる場合は、これを使用します。同じデータを使用する複数のビューがある場合は、データのフェッチ時間を節約できます。
非常に特定のデータセットを使用するビューがあり、ビューのレンダリングが複雑で、このビューが頻繁に要求された場合（たとえば、スタックオーバーフローのホームページ）、出力キャッシュから多くのメリットが得られます。
したがって、最終的には、それは本当にあなたのニーズに依存し、キャッシュを誤って使用することに注意してください。