オンラインの最初の日：あなたのサイトを殺さない方法
大量のデータ（大きな画像など）を含むこの豪華な新しいサイトがあり、それをオンラインにしようとしているとします。あなたが「あまりにも多くの」宣伝をすると、最初の数日間、サイトはリクエストで圧倒されます。
このリスクをどのように軽減できますか？
私は考えました
- SO and SF： "private" beta、public beta、publicのように徐々にライブになります
- xを許可する
接続同時にセッションを行うので、接続されたユーザーはまだサイトの良い経験を持っており、他のユーザーは素敵な謝罪メッセージを持っています
できません：
- 最初の数日後、サイトのトラフィックが大幅に減少するため、サーバーを追加購入します:)
- できるだけ多くキャッシュします。動的に作成されるページはすべて、ユーザーが静的バージョンを取得できるようにキャッシュする必要があります。ページコンポーネントでは、dbをクエリすることもキャッシュする必要があります。
- Amazon S3などの外部サービスを使用して画像やマルチメディアを提供してみてください（または、サイトが突然大量のトラフィックに見舞われた場合に使用できるようにしてください）。
ジェフとジョエルのブログの人気により、SOFとSFはすでに宣伝と需要が組み込まれているため、徐々にライブに移行することができます。彼らのようにほぼ保証されたユーザーベースがない場合、徐々にライブに移行することは致命的となる可能性があります。
非アクティブによって引き起こされるセッションの終了を定義するのは難しいため、同時セッションによる制限は避けます。ユーザーが15分間離れてページをリロードしようとすると、エラーメッセージが表示されるだけで、ユーザーを失っただけです。
データモデルにはどのくらいの計画がありましたか？高価な並べ替え、バイナリ列、複雑な結合なしでクエリの量を増やすことができるスキーマを設計しましたか？データベースバックエンドを調整しましたか（データベースバックエンドがあると仮定します）？
「大きな画像」をどのように提供していますか？それを別のWebサーバープロセス、さらには別のドメインに分割できますか？
システムの負荷テストを行いましたか？ ApacheBenchやSiegeのようなツールは非常に貴重です。
すべての構成はsvnにありますか？展開は自動化されていますか？アプリケーションを2番目のサーバーにロールアウトする必要がある場合は、それを喜ぶでしょう。
AmazonS3などの静的コンテンツのサードパーティホスティングを調べることをお勧めします。アプリケーションによっては、Amazon EC2を使用して一部をクラウド化することも価値があるかもしれません（流行語は嫌いです）。
リリース前に、堅牢な監視インフラストラクチャが整っていることを確認します。決定の基礎となるデータが必要です。つまり、サーバー全体のCPU負荷を測定し、負荷がボックス全体に均等に分散されていることを確認し、何かが溶けた場合は、それがどれであるかを確認します。
問題がどこにあるかを知ることで、対応にかかる時間が劇的に短縮されます。火が消えた後、後で設定することを意図して、監視せずに立ち上げるサイトが多すぎるのを見てきました。これはひどく間違っています。
招待システムは、ユーザーによるサイトの取り込みを制御するための優れた方法である場合があります。サイトが圧倒されないように、最初に一定数の招待状を配ります。次に、各ユーザーに他のユーザーに渡すための招待状をいくつか与え、サイトのユーザー数を徐々に増やしていきます。そうすれば、最初にサイトにアクセスする人が多すぎたり、トラフィックのピークが大きくなったりすることはありません。
もちろん、欠点は、最初は招待状を持たず、後で戻ってこない可能性のある多くのユーザーを拒否する可能性があることです。あなたが人々が使うことに非常に興奮している本当に良いサイトを持っていない限り、これは悪い動きかもしれません。本当にサイト次第です。さらに、招待システムを追加するには、実際には追加の開発時間が必要になります。
一部のホスティングプロバイダーでは、最大容量のプライベートサーバーをしばらくテストし、試用期間後に妥当な容量に落ち着くことができます。
DreamHostはその一例です。
http://www.dreamhost.com/hosting-vps.html