次の数日で私たちが技術的に鍛えるチャンスがあります。残念ながら、私たちはまだ生きていないので、私たちのシステムがどのようにプロダクションオーディエンスを担当しているかをよく見積もっていません。技術を鍛える方法を準備する
私たちの生産セットアップは、データベースサーバーとしてPostgresを使用して、それぞれが3つの雑種インスタンスを持つ2つのEngineYardスライスで構成されています。
明らかに、私たちのアプリの考え方の大部分は、実際のコードやクエリなどと関係しています。しかし、どのような種類の負荷や経験があるかについてのヒント/それを通過した人たちから6つの雑種インスタンス（サーバがそれをとることができるならば8かもしれません）は、負荷を処理するように聞こえるか、それとも少なくともほとんどですか？
私はFacebook上でのウイルス増殖のために負荷が高いいくつかのレールアプリケーションに取り組んできました。
あなたの雑種数は、いくつかの要因に基づいている必要があります。あなたの雑種がAPI呼び出しをしたり、電子メールを配信して応答を待つ必要がある場合は、可能な限り多く実行する必要があります。それ以外の場合は、CPUコアごとに1つの雑用を維持しようとします。
サーバーでフェアプロキシバランサ（ラウンドロビンではありません）を使用していることを確認してください。ここでこれを行いnginxのモジュールがある：http://github.com/gnosek/nginx-upstream-fair/tree/master
そしてここでは、負荷を処理するアプリケーションのパフォーマンスを改善し、ベンチマーク上の他のいくつかのヒントがあります：
ActiveRecordのが
最も一般的な問題は、アプリケーションの顔をレールActiveRecordオブジェクトの使い方が貧弱です。 1つだけが必要な場合は、100のクエリーを作成するのは非常に簡単です。これがアプリケーションで問題になるかどうかを判断する最も簡単な方法は、New Relicを設定することです。あなたのサイトの各メジャー・ページにリクエストした後、新しいSQLの概要を見てみましょう。非常によく似たクエリが多数表示されている場合（ID = 1の投稿から*を選択し、ID = 2の投稿から*を選択し、*から投稿を選択...）、これは次のものを使用する必要がある兆候です。あなたのActiveRecord呼び出しの1つに含まれています。
他のいくつかの基本的なActiveRecordのヒント
（これらは、私の頭の上から私は考えることができるだけのものです）：あなたはすでにそれをやっていない場合、正しく使用してくださいデータベーステーブルのインデックス。
ビュー内でデータベース呼び出しを行うことは避けてください。特に部分的には、ビューでどのくらいデータベースクエリを行っているかを追跡するのが非常に簡単です。すべてのクエリと計算をモデルまたはコントローラにプッシュします。
イテレータでクエリを作成しないようにします。通常これは：includeを使って行うことができます。
大規模なデータセット用のActiveRecordオブジェクトをできるだけ構築することは避けてください。 Post.find（：all）.sizeのような呼び出しを行うと、データベース内のすべてのPostに対して新しいクラスがインスタンス化されます（大きなクエリでも可能です）。この場合、Post.count（：all）を使用して、単一の高速クエリを作成し、オブジェクトをインスタンス化せずに整数を返すことができます。
User..has_many :objectsのような関連付けは、user.objectsとuser.object_idsの両方の方法を作成します。後者はActiveRecordオブジェクトのインスタンス化をスキップし、はるかに高速になります。特に多数のオブジェクトを処理する場合、これは高速化のための良い方法です。
可能であれば、named_scopeを学び、使用してください。コードを小さくすると、効率的なクエリを簡単に作成できます。リクエストを処理しているときに、外部サービスへのAPI呼び出しを行うことができませんできるだけ多くの
外部のAPI & actionmailerの
。応答が受信されるまで、サーバーはコードの実行を停止します。これはロード時間を増やすだけでなく、あなたの雑種は新しいリクエストを処理することができません。
リクエスト中に絶対に外部呼び出しを行う必要がある場合は、できるだけ多くの雑種を実行する必要があります。その多くがAPI応答を待っていて、何もしない状況に陥る可能性があるからです。 （これはFacebookアプリケーションを構築するときの非常に一般的な問題です）
場合によってはメールの送信にも同じことが言えます。多くのユーザーが短時間でサインアップすることを期待している場合は、ActionMailerがメッセージを配信するのに必要な時間をベンチマークしてください。ほとんど瞬間的でない場合は、電子メールをデータベースに格納し、別のスクリプトを使用して配信することを検討する必要があります。
BackgroundRBなどのツールがこの問題を解決するために作成されました。
キャッシュ
Here's a good guide on the different methods of caching in rails.
ベンチマーク（パフォーマンスの問題の場所） あなたは方法が遅くなることが疑われる場合は、コンソールでそれをベンチマークしてみてください。ここに例があります：
>> 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が最良のテストかもしれません。
サイトに数千の仮想ノードを生成し、その負荷からサーバーのパフォーマンスを検査できます。
のような弾力的なスケーリングはありません。それは私に情報ではなくコンテキストを与えます...私はそのポジションにいて、どんなストレスが与えられているかを見ている人からの経験が必要です。単純なリクエスト/秒の統計は、私のシステムがそのシナリオで十分に生存しているかどうかを必ずしも教えてくれません。 –
これは実際には1秒あたりのリクエスト数ではありません。サイトに何千ものノードが発生し、その負荷からサーバーのパフォーマンスを調べることができます。 – BobbyShaftoe
私の経験では、顧客の一部がクランチを吸収するのを見て、トラフィックはかなり控えめでした。骨の破砕スパイクの人々は期待していないようでした。さて、あなたがシンジケート化してYahooのページや何かを作るならば、物事は異なるかもしれません。
Facestat.comの経験を検索するあなたは、彼らがそれを取り扱うかについて読みたい場合は（ヤフーFP。）
私のアドバイスは、ちょうどサインアップをオフにしたり、より多くの静的バージョンに行くために準備されていますあなたのサーバーが暑すぎる場合はあなたのサイト。監視/プロファイリングツールを使用することも良いアイデアです。セットアップを簡単にするために、FiveRuns Manageツールが好きです。
あなたがEngineYardを使用しているので、あなたが必要
あなたの大きな問題は、おそらく着信要求の数ではありません場合は、負荷を処理するために複数のマシンを割り当てることができるはずですが、データの量になりますあなたのデータベースはあなたのクエリが期待しているインデックスを使用していない場所を示しているか、あまりにも多くのデータを返しています。ユーザーリストページは10人のユーザーで動作しますが、ページングを追加していないため、その1つのページに10,000人のユーザーを表示しようとすると死んでしまいます（will_paginateプラグインはほとんどあなたの友人です - 'select count（*）'
）あなたのために生成されたように、2つの物事が見て：＃1用のページ
あたり
これらのクエリをテストするためにデータベースをいっぱいにするのに役立つさまざまな種類のデータのためのデータを生成できるプラグインがあります。
＃2の場合は、ページごとのデータを減らすためにwill_paginateプラグインなどの方法を使用してください。
私たちは基本的にあなたと同じ設定、2つのプロダクションスライス、ステージングスライスをEYに持っています。私たちは大きな負荷テストツールであることを発見しました。ヒットしたいと思っているURLのbashスクリプトを作成し、それをあなたのスライスに向けます。NewRelicの統計情報を見ると、アプリで処理できる負荷と最適化が必要な場所を知ることができます。
また、query_reviewerも非常に便利であることがわかりました。それらの索引付けされていない表とn + 1個の照会を見つけるのに最適です。
EYの要点は、需要に沿ってスライスを増やすことができたと思いましたか？ – Chris
もちろんこれは可能ですが、それが起こってからそれを実現するまでの間に、またEYと実際にボックスをセットアップすることを伝えている間に、時間があります。 AmazonのECC –