5

Heroku でホストされているベータ前の Rails 3.2 アプリのパフォーマンスを改善しようとしています。

アグレッシブ キャッシングによって状況は劇的に改善されましたが、New Relic でのアプリ サーバーの応答時間 (グラフの水色) を見ると、「Ruby で費やされた時間」が依然として大きく寄与していることに気付きます。

Rails アプリのどの部分が、通常、この「Ruby 時間」に貢献していますか?

ruby で過ごした New Relic の時間

これは、メイン コントローラーの 1 つの複雑な条件が原因であると当初考えていましたが、単純化しました。私のビューは現在、ロシアンドールのフラグメントキャッシュと memcache を使用して非常に積極的にキャッシュされています (すごい!)。

静的アセットの提供が原因でしょうか? (S3 への移行 / CloudFont は todo リストにあります...)

ありがとう！

(私はすでにdelayed_jobのセットアップを行っており、できる限りすべてをバックグラウンドに移動しました。WebサーバーとしてUnicornも使用しています。)

更新されたパフォーマンス調整

積極的なキャッシングの後、アプリのパフォーマンスを向上させる他の方法を探し始めました。

最初にガベージ コレクションの監視を提案として追加しましたが、GC が Ruby の時間に大きく影響していないことがわかりました。

ここに画像の説明を入力

次に、CDN (CDNsumo アドオンを介した Cloudfront) を追加して、アセットの提供を開始することにしました。興味深いことに、これにより NR モニタリングでの Ruby の時間が実際に短縮されました。(CDN はプロビジョニングされ、下のグラフの右端にある最後のリクエスト テストによってウォームアップされました。) 私のページのほとんどには、数百キロバイトの CSS と JavaScript があります。

ここに画像の説明を入力

最後に、'Basic' スターター データベースから最小の実稼働データベース 'Crane' にアップグレードしました。これは、パフォーマンスに劇的な影響を与えました。PG による少しのキャッシュの後、アプリは動作します。(下のグラフの最後の 3 つの要求スパイク)。

ここに画像の説明を入力

Heroku アプリの調整を試みている他のユーザーへのメッセージ:

  • 複数の領域 (キャッシング、CDN、データベース、Ruby コードなど) での単純なパフォーマンス チューニングは、スタック全体で相乗効果をもたらします。
  • 逆に、1 つのパフォーマンスの低下は、他の領域を調整しても克服できないボトルネックになります (つまり、Heroku の遅いスターターの Basic または Dev データベースと「高価な」本番データベース - 遅い Basic データベースがアプリのパフォーマンスを犠牲にしていました) ）。
  • NewRelic は、どこで最大の利益を得ることができるかを判断する上で不可欠です。
4

1 に答える 1

7

「Ruby」の時間は、実際には NewRelic トレースの「その他」のバケットです。他のカテゴリは明示的な測定値です (つまり、memcached への呼び出しに費やされた時間)。Ruby 時間は、これらのバケットの 1 つに費やされていないすべての時間です。

では、「Ruby」の時代には他に何が起こるのでしょうか? 一番の候補はガベージコレクション（GC）です。config/initializers/newrelic.rbRuby 1.9 以降を実行している場合は、次のように初期化子を作成することで、GC の NewRelic プロファイリングを有効にすることができます。

GC::Profiler.enable

これにより、GC 時間が別の NewRelic カテゴリとして追跡されます。

GC の調子が良い場合、次のステップは Web トランザクション ビューを使用して、これらの平均時間がどのように分布しているかを確認することです。おそらく、アプリケーション内の 1 つまたは 2 つのアクションがひどいパフォーマーであり、これらの平均の原因となっている可能性があります。

それでも問題が解決しない場合は、お気軽に直接お問い合わせください。パフォーマンス チューニングは黒魔術です。

于 2013-09-21T15:57:32.357 に答える