生産のためのRailsパフォーマンスチューニング？

Question

Rails 3.1.x上に構築されたアプリケーションのデプロイに近づき、いくつかのパフォーマンステストを開始しました。 abでちょっと試練した後、私はHerokuで約15リクエスト/秒を返すという非常に落胆した結果を見ています。

ローカルでテストすると、アプリの問題が何よりも重要であることが実際に実証された同様の結果が表示されます。

私はUnicornを使用しています。これは、Thin on Celadon Cedarよりも約40％高速です。さらに、私はPGSQL共有dbを使用しています。

私は、誰かが洗濯物のリストや基本的に起動チェックリストを共有できることを期待しています。これは、プロダクションのためにアプリを準備し、速度調整の必要性に移行するときに移動する必要があります。これまでのところ私はではありませんでした。は、私の状況を考えると意味をなさないと思われる実行可能なアイテムの実際の簡潔なリストを発見しました。

また、このような問題を解決する実践的な経験があれば、どんなインプットにも感謝します！

Answer 1

私はherokuで自分のアプリをチューニングするのに少し時間を費やしていましたが、さまざまな設定でRailsアプリケーションのパフォーマンスチューニングに時間を費やしました。

私は実行するとABは-n 300 -c 75 ... myapp.com ....＃私のメイン・サイトにバックアップされ、そしてユニコーン

Requests per second: 132.11 [#/sec] (mean) 
Time per request:  567.707 [ms] (mean) 
Time per request:  7.569 [ms] (mean, across all concurrent requests) 

で無料の杉の計画であります（これは強烈なことを何もしていないホームページであるため、私はそれを単に「非常に簡単なページを使って無料プランに入れることができるだろうか？」という例としてのみ提供しています。ここでは、この高速」）

は私のRailsのパフォーマンス・チューニング101チェックリストです：

1. 最初にブラウザ/ページの読み込み時間を測定します（ブラウザは多くのリクエストを行い、abはその1つについてのみ伝え、通常はメインページのリクエストは問題ではありません）。www.webpagetest.orgなどのツールからページ読み込みベースライン番号を取得するか、パブリックに面するページの場合はwww.gtmetrix.com、非公開のページの場合はブラウザツールYslow、Googleページの速度、またはdynatrace。ページロードのウォーターフォールダイアグラム（chrome/firefoxの 'Net'パネル）を見ると、通常はhtmlが素早く（秒で）ロードされますが、それ以外のものはロードするのに1〜3秒かかります。改善する方法についてのYslow /ページスピードの推奨事項に従います（Rails 3.1のアセットパイプラインを最大限に活用していることを確認してください）

2. ログファイル/新しい遺物を読み、「最も遅い/最も頻繁にヒットした 'リクエストと、そのリクエストに対して何が起きるかをプロファイルする（ルビーが遅い/ memの使用量が多い、あるいはたくさんのクエリですか？）パフォーマンスの問題を検出して監視する信頼できる方法が必要です物事は無作為に。ターゲット領域を特定したら、テスト前後のテストに役立つテストスクリプトを作成し、変更が役立つことを証明し、回帰がうまくいくかどうかを検出します。

3. dbカラムのインデックスの欠落は最も一般的です問題を解決し、最も簡単に対処します。ターゲット・クエリーでexplainを実行するか、低速クエリー・ログを調べて、クエリー・プランナーが何をしているかを確認します。必要に応じて、外部キー、検索列、または主要データ（索引をカバーする）の索引を追加します。実際の生産データを再テストして、違いがあることを証明します。 （あなたはherokuで説明を実行することができ、欠落しているか使用していないインデックスのクエリを実行することもできます）

4. ほとんどのパフォーマンスの低いRailsアプリケーションは、N + 1クエリに苦しみます。order.owner.address.cityループの中で何が起こるか考えてみてください。N + 1個のクエリは、必ずしも遅いクエリではないので、遅いクエリログには表示されず、多くのクエリが存在し、一度にすべてのクエリを効率的に実行できます。そのデータを積極的に読み込むにはincludeまたは.includes（）を使用するか、別の方法でクエリを実行します。

5. アプリのフローを分析し、キャッシングの機会を探します。ユーザーが索引ページと詳細ページの間を行き来して戻ってきた場合、おそらく詳細のAjaxビューが索引ページを離れずに、必要なデータをより迅速に提供します。私は今年のWindyCityRails会議でシカゴでこれらの技術および他のアイデアについてのプレゼンテーションを行いましたいくつかのmore thoughts about that on my blog

を書きました。あなたはできますsee the video here on my www.RailsPerformance.com blog 私が英雄について愛しているのは、あなたが最初からスケーラブルでなければならないということです。メーリングリストのディスカッションを見ると、ほとんどの人がパフォーマンスのベストプラクティスとサーバーを最大限に活用する方法を認識していることがわかります。私はまた、あなたが安く滞在したい場合、どのようにパフォーマンスチューニングの仕組みがあなたに最も魅力的なものになるかを学びます。

幸運を祈る！あなたは、通常のRailsアプリケーションでのSQLクエリを記述していないと（述べたように）サーバーの設定とハードウェアがHerokuの上無関係なので

Answer 2

まだ何も出ていないので、私はPostgreSQL部分の答えを提供します。私はRubyを手助けすることはできません。

パフォーマンスを最適化するための優れた出発点は、PostgreSQL wikiで見つけることができます。

• チューニングserver settings（Herokuので可能ですどのくらいかわからない）
• がslow queries
• に特別な注意を払うあなたのhardware（Herokuのでは適用されません）を確認し

Answer 3

最も包括的な単一の回答NewRelicのようなものを使ってアプリケーションを計測し、遅い場所を見つけることです。次に、コードに最適化やキャッシングを適用して、それらの遅い箇所を滑らかにします。 Herokuのお客様は、無料でNewRelicをインストールできます。これは、Herokuコンソールから展開に追加できるアドインです。

何が減速しているのか分かったら、それに近づくことができます。 Herokuはパフォーマンスのチューニングのデベロッパー・エンドのほとんどを処理するので、何もする必要はありません。しかし、データベースクエリを最適化し、必要に応じてフラグメントレベルとアクションレベルのキャッシュを実行することで、大きな利益を得ることができます。

Answer 4

ほとんど常にかなり立派な性能向上が得られ、かなりの低ぶら下げ果実があります

1. は、より効率的なActiveRecordの文を使用してDBクエリの数を減らします。適切な場合はincludeとjoinを使用し、COUNTが必要な場合はをany?に、可能であればSELECTを避けるようにしてください。
2. 特に重いページでは、わずか数分であってもビューをキャッシュします。より大きなまたは動的な部分を、部分的なものに分割して、悪影響を及ぼすことなくキャッシュすることができます。
3. ネットワーク越しのアクティビティをバックグラウンドジョブに移動します。これには、電子メールの送信、他のWebサイトからのページの取得、APIコールの実行（[特に？]をHerokuにする）などがあります。Rubyには本当に良いバックグラウンド処理ライブラリがたくさんありますが、DelayedJobはActiveRecordデータベースで動作するので本当に人気がありますが、私のお気に入りはResqueです。

Rubyルーチンを最適化するのにあまり時間を費やさないように注意する必要があります。大量のデータや処理（たとえば画像のサイズ変更）を行っているものでなければ、ループの最適化やメモリ使用量の最小化によって大きなメリットは得られません。特定のページに問題があるとわかった場合は、ログを掘り下げて、そのリクエスト中に何が起きているのかを確認してください。

また、HireFireAppのようなオートスケーリングアプリケーションは、余分なdynosを低速で実行するコストをかけずに、水平方向にスケーリングすることで、多くの要求を処理するのに最適です。

PS：最大で5,000ユーザーの同時負荷をテストできるBlitzと呼ばれる新しいHerokuアドオンがあります。