今後数日で技術的な問題が発生する可能性は十分にあります。残念ながら、私たちはまだライブに移行していないため、システムが本番環境の視聴者をどのように処理するかを正確に見積もることができません.
私たちの実稼働セットアップは、データベース サーバーとして Postgres を使用して、それぞれ 3 つの mongrel インスタンスを持つ 2 つの EngineYard スライスで構成されています。
明らかに、私たちのアプリがどのように持ちこたえるかの大部分は、実際のコードやクエリなどを処理することです。ただし、予想される負荷の種類に関するヒント/ポインターがあるかどうか、または持っている人々からの経験があるかどうかを確認することをお勧めします。それを経験しました。6 つの mongrel インスタンス (サーバーが処理できる場合はおそらく 8 つ) で負荷を処理できるように思えますか、それとも少なくともそのほとんどでしょうか?
私はいくつかの Rails アプリケーションに取り組んできましたが、これは Facebook でのバイラルの増加により高負荷が発生しました。
雑種の数は、いくつかの要因に基づいている必要があります。雑種が API 呼び出しを行ったり、電子メールを配信したりして、応答を待つ必要がある場合は、できるだけ多く実行する必要があります。それ以外の場合は、CPU コアごとに 1 つの mongrel を維持するようにしてください。
サーバーが Fair Proxy Balancer (ラウンド ロビンではない) を使用していることを確認してください。これを行う nginx モジュールは次のとおりです: http://github.com/gnosek/nginx-upstream-fair/tree/master
また、負荷を処理するためにアプリケーションのパフォーマンスを改善およびベンチマークするためのその他のヒントを次に示します。
アクティブレコード
Rails アプリケーションが直面する最も一般的な問題は、ActiveRecord オブジェクトの不適切な使用です。必要なクエリが 1 つだけの場合でも、何百ものクエリを作成するのは非常に簡単です。これがアプリケーションの問題であるかどうかを判断する最も簡単な方法は、 New Relicをセットアップすることです。サイトの主要な各ページにリクエストを送信したら、newrelic SQL の概要を確認してください。非常によく似たクエリが連続して大量に表示される場合 (select * from posts where id = 1、select * from posts where id = 2、select * from posts...)、これは次を使用する必要があることを示している可能性があります。 ActiveRecord 呼び出しの 1 つに含めます。
その他の基本的な ActiveRecord のヒント (これらは、私が頭の中で思いつくものにすぎません):
まだ行っていない場合は、データベース テーブルでインデックスを正しく使用していることを確認してください。
ビュー、特にパーシャルでデータベース呼び出しを行うことは避けてください。ビューでデータベース クエリをどれだけ行っているかを簡単に把握できなくなる可能性があります。すべてのクエリと計算をモデルまたはコントローラーにプッシュします。
イテレータでクエリを作成しないでください。通常、これは :include を使用して実行できます。
Rails で大規模なデータセットの ActiveRecord オブジェクトを構築することは、できる限り避けてください。Post.find(:all).size のような呼び出しを行うと、データベース内のすべての Post に対して新しいクラスがインスタンス化されます (これも大きなクエリになる可能性があります)。この場合、単一の高速クエリを作成し、オブジェクトをインスタンス化せずに整数を返す Post.count(:all) を使用することをお勧めします。
およびメソッドUser..has_many :objectsの両方を作成するような関連付け。後者は ActiveRecord オブジェクトのインスタンス化をスキップするため、はるかに高速になります。特に、多数のオブジェクトを処理する場合、これは処理速度を上げる良い方法です。user.objectsuser.object_ids
可能な限り、named_scope を学習して使用してください。コードを小さく保つのに役立ち、効率的なクエリを簡単に作成できます。
外部 API と ActionMailer
リクエストの処理中は、できる限り外部サービスへの API 呼び出しを行わないでください。サーバーは、応答が受信されるまでコードの実行を停止します。これによりロード時間が長くなるだけでなく、mongrel が新しいリクエストを処理できなくなります。
リクエスト中に絶対に外部呼び出しを行う必要がある場合は、できるだけ多くの mongrel を実行する必要があります。なぜなら、mongrel の多くが API 応答を待っているだけで他に何もしていないという状況に遭遇する可能性があるからです。(これは、Facebook アプリケーションを構築する際によくある問題です)
場合によっては、電子メールの送信にも同じことが当てはまります。短期間に多くのユーザーがサインアップすると予想される場合は、ActionMailer がメッセージを配信するのにかかる時間を必ずベンチマークしてください。すぐに送信できない場合は、メールをデータベースに保存し、別のスクリプトを使用して配信することを検討してください。
この問題を解決するために、BackgroundRBなどのツールが作成されました。
キャッシング
これは、レールでキャッシュするさまざまな方法に関する優れたガイドです。
ベンチマーク (パフォーマンスの問題の特定) メソッドが遅いと思われる場合は、コンソールでベンチマークしてみてください。次に例を示します。
>> Benchmark.measure { User.find(4).pending_invitations }
=> #<Benchmark::Tms:0x77934b4 @cutime=0.0, @label="", @total=0.0, @stime=0.0, @real=0.00199985504150391, @utime=0.0, @cstime=0.0>
アプリケーションで遅いメソッドを追跡します。これらは、頻繁に実行することを避けたいものです。Rails にはクエリ キャッシュがあるため、最初の呼び出しだけが遅くなる場合があります。Memoizationを使用して、メソッドを自分でキャッシュすることもできます。
NewRelic は、メソッドと SQL 呼び出しの実行にかかる時間の概要も提供します。
幸運を！
WEBLoadなどの負荷テスト ソフトウェアを検討するか、お金がある場合は Quick Test Pro を検討してください。これは、いくつかのアイデアを提供するのに役立ちます。あなたの状況では、WEBLoad が最適なテストかもしれません。
サイトにヒットする数千の仮想ノードを生成し、その負荷からサーバーのパフォーマンスを調べることができます。
あなたの大きな問題は、おそらく着信リクエストの数ではなく、データベース内のデータの量であり、クエリが期待するインデックスを使用していないか、またはあまりにも多くのデータを返している場所を示しています。ページネーションを追加していないため、10,000 人のユーザーをその 1 つのページに表示しようとすると死亡します (will_paginate プラグインはほとんどあなたの友達です - あなたのために生成される 'select count(*)' クエリに気をつけてください)
したがって、注目すべき2つのこと：
＃1については、すべてのクエリの後に「explain ...」クエリを実行するプラグインがあるため、インデックスの使用状況を手動で確認できます
さまざまな種類のデータのデータを生成できるプラグインがあり、これらのクエリをテストするためにデータベースを埋めるのに役立ちます.
#2 については、will_paginate プラグインまたはその他の方法を使用して、ページあたりのデータを減らします。
一部のお客様がクランチを吸収するのを見た私の経験では、トラフィックはかなり控えめで、人々が期待するような骨を砕くスパイクではありませんでした. 今、シンジケートされて Yahoo のページか何かで作成された場合、状況が異なる可能性があります。
彼らがそれをどのように処理したかについて読みたい場合は、Facestat.com の経験を検索してください (Yahoo FP)。
私のアドバイスは、サーバーが熱くなりすぎた場合は、サインアップをオフにするか、サイトのより静的なバージョンに移動する準備をすることです. 監視/プロファイリング ツールを使用することも良い考えです。セットアップが簡単な FiveRuns Manage ツールが気に入っています。
EngineYard を使用しているため、必要に応じて負荷を処理するためにより多くのマシンを割り当てることができるはずです