少なくともすべての静的コンテンツを除外します。別の場所に別の vhost をセットアップし、すべてのグラフィックス、CSS、および JavaScript をそこにロードします。追加のサイクルを購入して、そのタイプのコンテンツの提供をオフロードできます。どうしても気になる方は、コンテンツ配信サービスに登録してご利用ください。現在、Akamai に類似した非常に安価な製品が多数あります。
もう 1 つのアイデアは、Apache mod_proxy を利用して、生成されたページ出力を特定の時間維持することです。 APCも非常に便利です...出力バッファリングキャプチャ+ページ上の関連データの最終変更時刻を採用し、APCキャッシュバージョンを使用できます。ページが有効でなくなった場合は、再生成して APC に再度保存します。
幸運を。学習体験になります!
最初に測定し、次に最適化します。負荷テストを行ったことはありますか?ボトルネックはどこにありますか?
ボトルネックがわかれば、追加のデータベース ボックスまたは Web ボックスが必要かどうかをインテリジェントに判断できます。現時点では、推測にすぎません。
また、負荷テストの結果は、予想されるトラフィックとどのように比較されますか?予想されるトラフィックの 2 倍を処理できますか?五回？追加のハードウェアをどのくらい簡単に入手してリリースできますか?ビジネス要件は、立ち上げ中に失敗しないことだと確信しているので、たくさん持っていることを確認してください 利用可能な容量。後で負荷が安定し、何が必要かがわかったら、いつでも解放できます。
処理できる限り多くのユーザーを受け入れ、サイトのパフォーマンスを測定し、ライブに移行する前にバグを解決するベータ期間を設けてください。
プライベート ベータでユーザー数を明示的に制御するか、各ユーザーが友人に紹介できる多数の紹介者を持つ Google スタイルのセミパブリック ベータで制御できます。
スパイク (またはピーク) パフォーマンスを準備または処理するには、まず jmeter などを使用した簡単なパフォーマンス テストを通じて、準備ができているかどうかを判断します。
セットアップと開始が簡単で、予想されるピーク負荷を処理できるかどうかを早期に判断できます。
ただし、時間の制約がある場合は、最も注目を集めるコンテンツの静的バージョンを準備する必要があります (リリース日の場合はプレス リリースなど)。また、クライアント側のキャッシュを最大限に活用していることを確認してください (サーバーへの要求を 1 つ減らすだけで、すべてが変わります)。 Web はすでに非常に高いスケーラビリティを実現するように設計されており、コンテンツ キャッシングを効果的に使用することは、このような状況での最良の友です。
物事が落ち着いたら、新しいガーディアン Web サイトの設計に関するソフトウェア エンジニアリング ラジオの高いスケーラビリティに関する優れたポッドキャストがあります。
打ち上げ頑張ってください。