私はソーシャルネットワークサイトを開発中です。
そして、プロジェクトの初日からスケーラビリティについて考えていたので、サイトとクエリを可能な限り微調整しました。
でも; 特定のページは非常にデータ量が多く、ロードが可能な限り高速であるかどうかはよくわかりません。そのため、分散キャッシュソリューションの実装を考えていました。
しかし、何をキャッシュすべきか、キャッシュすべきではないかはよくわかりません。または、現在のページの読み込み時間が1秒であるかどうか。
最も重いクエリは、メンバー情報を取得することです。このクエリは、すべてのメンバーの情報と、このサイトの場合の目標、ブログタイプのエントリ、励まし、写真、ステータスの更新（Twitterなど）、ブログ情報（エントリのクロスポスト用）など、メンバーに関連するすべての情報を取得します。 ）などなど。
とにかく、この情報をキャッシュする必要がありますか？そして、1秒のページの読み込み時間はかなり速いと思いますか？一部のページは、4〜6の10分の1秒の間で1秒未満です。
典型的な答えは次のとおりです。
あなたの場合、フラット ファイル (たとえば、ユーザーごとに 1 つのファイル) にすべてをキャッシュし、対応するものによって何かが更新されるたびにユーザー キャッシュ ファイルを破棄することができます。キャッシュ ファイルが存在しない場合は、関連するコンテンツを表示する前に作成します。
読み込み時間 (ユーザーの場所によって大きく異なる場合があります) については、ゲーム サイトの PHP フォーラムからの有益な数値を以下に示します。
そして、これはコミュニティによって良い経験と見なされています。しかし、それはひどく主観的です。
可能であれば、アプリケーションのすべてのレイヤーにキャッシュを実装します。
ページを最上位レベルで、オブジェクトをコード レベルでキャッシュし、データベースがクエリとキー データの両方を最下位レベルで正しくキャッシュしていることを確認できます。
キャッシュする必要があるものに関しては、繰り返しアクセスされるオブジェクト、特に頻繁に変更される可能性が低いオブジェクトをキャッシュする必要があります。その後、そのオブジェクトが編集されたときにのみ、そのオブジェクトのキャッシュをリセットできます。(頻繁に更新されるオブジェクトのキャッシュには注意してください。ほぼすべてのロードでキャッシュを置き換える一定のサイクルは、パフォーマンスを向上させるどころか低下させます)
パフォーマンスを測定するために、1 つのページの読み込みにかかる時間は調べませんが、プレッシャー下で各ページのパフォーマンスを実際にテストする必要があるため、いくつかのパフォーマンス測定ツールをグーグルで検索します。たとえば、めったにアクセスされない場合、ユーザー情報ページは最大のキャッシュ対象ではない可能性があります。最も頻繁に使用されるページに焦点を当てる必要があります。
ページの読み込みに関する質問はすでに行われています。
動的でパーソナライズされたWebアプリケーションの適切な応答時間とは何ですか？
キャッシュに関しては、キャッシュからのロードと比較して、毎回データのロードに費やされる時間を測定する必要があります。キャッシュが大きいほど、効果は低くなります。したがって、キャッシュに大量のデータをロードする必要はありません。ここで使用するのはローリングキャッシュであり、キャッシュサイズの制限に達すると、使用頻度の最も低いデータが削除されます。次に、実際のパフォーマンス結果に従って制限を調整します。
ユーザープロファイル固有のデータについては、FormsAuthチケット/Cookieにできるだけ多く保存してください。（HttpContext.Current.Cache）ユーザー固有のアイテムをキャッシュするには、セッションと同じように、ユーザーごとにサーバー上にXリソースが必要になります（ただし、頭痛の種は少なくなります）。ユーザーのチケットまたはCookie（4Kなど）に可能な限りオフロードできる場合は、スケーリング中にサーバーのパフォーマンスを大幅に向上させることができます。
ページに必要な情報のビットのみを取得する必要があります。たとえば、ブログデータを読み込む場合は、写真を読み込まないでください。はい、それ以上の作業ですが、スケーリングする場合は、各ページのニーズを分析する必要があります。
データベースクエリキャッシング（実行プランの再利用）、オブジェクトキャッシング（Httpcontext.Cache）、およびページキャッシング（Response.Headers [Expires]）には違いがあることを理解してください。
一部の調査では、対話型アプリケーションは 250 ミリ秒以内にフィードバックを提供して、ユーザーが動かなくなった、または操作が失敗したと思わないようにする必要があることが示唆されています。ただし、Web での受け入れレベルはやや高く、通常、新しいページが読み込まれているというフィードバックが Web ブラウザーから提供されます。ただし、AJAX では、ブラウザーが何が起こっているのかを表示しないため、何らかのフィードバックを提供するように注意する必要があります。
Web デザインの第一人者であるVincent Flandersは、4 秒を超えるものは長すぎて Web ページを読み込めないと示唆しています。これはかなり良い経験則だと思います。
キャッシュやその他のパフォーマンスの最適化に関する限り、パフォーマンス テストを実行することをお勧めします。市場には、多数のパフォーマンス テスト キットが販売されています。テストにより、問題のある領域がどこにあるかが示されます。すでにうまく機能しているものにキャッシング ロジックを追加しても意味がありません。一方、キャッシュを考慮していなかったデータが関係して、予期しない場所でパフォーマンスの問題が発生する場合があります。
また、パフォーマンス テストでわかったことは、コード内でデッドロックが発生している場所や、単純なデータベースの最適化が役立つ場所を見つけることができるということです。おそらく、テーブルにインデックスを追加すると、一連のキャッシュ ロジックを追加する代わりにページが高速化されます。
私はそれをシンプルに保ち、あなたがそうする必要がある場合にのみパフォーマンスをリファクタリングします。
また、早期にテストし、頻繁にテストします。多くの人がパフォーマンスを最後に考えるように言っていることは知っていますが、少なくとも開発ライフサイクルの早い段階でパフォーマンスを考慮し始めなければ、コーディングは本当に窮地に陥る可能性があります。