いつ、どのようにキャッシュするかを決定する際に、どのような懸念事項、プロセス、質問を考慮しますか。それは常に勝てない状況ですか?
これは、最適化されたコード ベースに行き詰まっていることを前提としています。
いつ、どのようにキャッシュするかを決定する際に、どのような懸念事項、プロセス、質問を考慮しますか。それは常に勝てない状況ですか?
これは、最適化されたコード ベースに行き詰まっていることを前提としています。
私は最近、WebアプリケーションでDotNetNukeを使用していますが、キャッシュソリューションを実装するたびに考慮すべきことがいくつかあります。
まず、あなたが言ったようにコードが最適化されている場合、サイトが多くのリクエストで打たれているときにのみ、顕著なパフォーマンス上の利点が見られます。
ただし、ディスクからよりもRAMからリソースをプルする方が高速であるため、キャッシュ戦略を実施している場合は、Webサーバーがより多くのリクエストを処理できるようになります。
キャッシュが必要になる時期を知ることに関しては、ローエンドの最新のWebサーバーでさえ、1秒あたり数百のリクエストを処理できることを考慮してください。したがって、適切な量のトラフィックを期待しない限り、キャッシュはおそらくスキップできるものです。
また、データベースからコンテンツをプルする場合(たとえば、StackOverflowがこれを実行する場合)、データベース操作は比較的コストがかかり、大量の状況では大きなボトルネックになる可能性があるため、キャッシュは非常に役立ちます。
キャッシュが適切でない場合やキャッシュが困難になった場合のシナリオについて...たとえば、現在の日付と時刻を表示する動的ページをキャッシュしようとすると、取得しない限り、常に古い日付/時刻が表示されます。キャッシング戦略にもう少し関与します。ですから、それについて考える必要があります。
あなたのウェブサイト/アプリケーションの各機能を見て、各機能について決定します。
私は個人的に、ウェブサイト/アプリケーションのセクションをキャッシュすることを支持して、ページ全体をキャッシュすることに反対します.
どの言語を使用していますか?ASPを使用すると、メソッドにプロパティタグを追加するだけで非常に簡単にキャッシュでき、時間に応じて値がキャッシュされます。
キャッシュをさらに制御したい場合は、MemCachedなどの一般的なシステムを使用して、時間またはイベントごとに制御できます。
たとえば、YahooはJavaScriptを「バージョン管理」しているため、ブラウザはcode-1.2.3.jsをダウンロードし、新しいバージョンが表示されると、そのバージョンを参照します。これを行うことで、Javascriptコードを非常に長い間キャッシュ可能にすることができます。
一般的な答えとしては、データによって異なりますが、どのくらいの頻度で変更されるかによって異なります。たとえば、画像はあまり頻繁に変更されませんが、HTMLページは変更されます。「Aboutus」ページはあまり頻繁に変更されませんが、ニュースセクションは変更されます。
時間ごとにキャッシュできます。これは、変化の速いデータに役立ちます。30秒または1分の時間を設定できます。もちろん、これにはある程度のトラフィックが必要です。トラフィックが増えるほど、時間で遊ぶことができます。これは、1時間に1回の訪問がある場合、この訪問はキャッシュに入力され、使用されないためです...
イベントごとにキャッシュできます...データが変更された場合は、キャッシュを更新します...これは、データがユーザーにとって非常に高速である必要がある場合に非常に便利です。
変更されないことがわかっている静的コンテンツをキャッシュできます。毎日更新されるトップ10がある場合は、すべてをキャッシュに保存して毎日更新することができます。
可能な場合は、オブジェクト全体のメモリキャッシュに注意してください。ASPNETでは、これは組み込みの機能であり、ビジネスロジックオブジェクトをIISアプリケーションに配置し、そこからアクセスすることができます。
これは、ページを生成するために必要なすべてのものをメモリに保存し(データベースへの書き込みを永続化)、データベースIOなしでページを生成できることを意味します。
ページを生成するには、ページ作成ロジックを使用する必要がありますが、データの取得にかかる時間を大幅に節約できます。
他の手法には、ローカライズされた出力キャッシュが含まれます。このキャッシュでは、送信する前に出力をキャプチャしてファイルに保存します。これは静的セクション(特定のページのナビゲーションやテキスト本文など)に最適であり、要求されたときにそれらを含めます。ほとんどの実装は、書き込みが発生したとき、または一定期間後に、このようにキャッシュされたオブジェクトをパージします。
次に、「正確さ」が最も低くなります。つまり、ページ全体のキャッシュです。最高のパフォーマンスを発揮しますが、非常に単純なページがない限り、かなり役に立ちません。
キャッシングの種類は?サーバーサイドキャッシング?クライアント側のキャッシング?
クライアント側のキャッシングは、静的 HTML、SWF、画像などの特定のものについては簡単です。アセットが変更される可能性が高い頻度を把握し、必要に応じて「Expires」ヘッダーを設定します。(2日? 2週間? 2ヶ月?)
定義上、動的ページはキャッシュするのが少し難しくなります。Javascript を使用した特定のチャンクのキャッシング (および JS が利用できない場合は IFrame への劣化) についていくつか調査が行われました。
DB およびアプリケーション レベルのキャッシュは、状況に応じて機能する場合と機能しない場合があります。それは、ボトルネックがどこにあるかによって大きく異なります。アプリケーションがページ レンダリングに最も多くの時間を費やしている場所を特定することが、おそらく優先度 1 です。次に、キャッシュの場所と方法を検討します。