私は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)
（これは、強烈なことを何もしないホームページに反するため、「非常にシンプルなページで、herokuを無料プランでどれだけ速くできるか」という例としてのみ提供します。「アプリはこの速さ」）
Rails PerformanceTuning101のチェックリストは次のとおりです。
-
最初にブラウザ/ページの読み込み時間を測定し（ブラウザは多くのリクエストを送信します。abはそのうちの1つについてのみ通知します。通常、メインページのリクエストは問題ではありません）、
-
ログファイル/新しい遺物を読んで、「最も遅い/最も頻繁にヒットする」リクエストのスイートスポットを見つけ、そのリクエストで何が起こるかをプロファイルします（遅いルビー/大量のメモリ使用、または大量のクエリですか？）物事をランダムに変更するだけでなく、パフォーマンスの問題を検出および監視するための信頼できる方法を用意すること。いくつかのターゲット領域を特定したら、テストの前後に役立つテストスクリプトを作成し、変更が役立つことを証明し、リグレッションが忍び寄るかどうかを検出します。
-
db列のインデックスの欠如は、最も一般的な問題の1つであり、最も簡単に対処できます。ターゲットクエリでexplainを実行するか、遅いクエリログを調べて、クエリプランナーが実行していることを確認します。必要に応じて、外部キー、検索列、またはプライマリデータ（カバーするインデックス）のインデックスを追加します。実際の生産データで再テストして、違いが生じることを証明します。 （herokuでexplainを実行したり、欠落しているインデックスや未使用のインデックスのクエリを実行したりできます）
-
パフォーマンスの低いRailsアプリのほとんどは、order.owner.address.cityを非常に簡単に記述でき、ループ内で何が起こるかを考えていないため、N+1クエリに悩まされています。 N + 1クエリは必ずしも遅いクエリではないため、遅いクエリログには表示されません。クエリがたくさんあるだけで、一度にすべてを実行する方が効率的です。 ：includeまたは.includes（）を使用して、そのデータを積極的に読み込むか、別の方法でクエリを実行することを検討してください。
-
アプリのフローを分析し、キャッシュの機会を探します。ユーザーがインデックスページと詳細ページの間を行き来し、また戻ってきた場合、インデックスページを離れることなく、詳細のajaxビューを使用すると、必要なデータをより迅速に取得できます。 ブログにもっと考えを書いた>
今年のWindyCityRailsカンファレンスで、シカゴでこれらのテクニックやその他のアイデアについてプレゼンテーションを行いました。 こちらのビデオをwww.RailsPerformanceでご覧いただけます。 .comブログ 私がherokuで気に入っているのは、最初からスケーラブルでなければならないということです。メーリングリストのディスカッションを見ると、ほとんどの人がパフォーマンスのベストプラクティスと、サーバーを最大限に活用する方法を認識していることがわかります。私はまた、あなたが安く滞在したいのであれば、あなたがあなたに最大の価値をもたらすパフォーマンスチューニングのトリックを学ぶ方法が好きです。
頑張ってください！