私のレールアプリケーションにパフォーマンスのボトルネックの原因となっているものを特定できません

Question

私のherokuログによれば、私のレールアプリは平均1700〜2500ミリ秒のリクエストを処理しています（これは往復全体です）。私は自分のアプリケーションのプロファイルに新しい遺物を使いました。その要求の大半は自分のデータベースではなく、New Relicの "Web Transaction"セクションに費やされているようです。 "コントローラ"カテゴリは要求の中で最も遅くなる傾向があり、その後に "データベース"カテゴリの "SQL - SELECT"セグメントが続くようです。

私のコントローラーでパフォーマンスのボトルネックが発生する可能性があるとは思っていませんし、プレミアムバージョンを支払わずに新しい遺物に深く浸ることもできません。私は最近、アプリケーションの外部キーにインデックスを追加しましたが、これはデータベースの応答時間の点で大きな違いはなかったと思います。

私は、これらのボトルネックの原因を突き止めるのに十分な情報ではないことを知っていますが、私はどこから始めようと、何を提供するのかさえ分かりません。これらの問題を診断するためにどのような情報が必要か教えてくれれば助かります。

Answer 1

Rubyの新しいRelicには、無料のスタンドアロンデベロッパーモードが含まれています。 RAILS_ENV = developmentで動作している場合、New Relic gemは各リクエストの詳細なプロファイルを表示するルートを追加します。アプリを数回押してからhttp://localhost:3000/newrelicにアクセスしてください。

プロファイルには、各SQLクエリの時間とコードのコンポーネントが含まれます。 custom instrumentationを使用すると、大量のコードを小さなセグメント（または個々のメソッド）に分解して別々に取得することができます。この機能は、有料のProバージョンで得られるトランザクションのトレースとよく似ています。大きな違いの1つは、プロダクションで無料の開発モードを実行したくないということです。

（フル開示：私はNRのために働く多くの人々は、しかし、無料のdevのモードについて知っているので、私はそれが言及する価値があったと思っていません。）

あなたが潜在的にJavascriptのロードのようなものでも、より早く表示させることができhead.jsは、JSファイルを非同期に並行して読み込みます。

Answer 2

は、このスライドショーを見てみましょう：

http://www.slideshare.net/drhenner/optimize-the-obvious-7636674

は十分ではないかもしれませんが、それはいくつかの共通の障害を通過します。

少しdeaperはこのビデオを見てみましょう掘る：http://windycityrails.org/videos2011/#2

それは長いですが、見て多くの場所を提供します。

CDNを使用していますか？