4

Rails 3.0.0 と Ruby 1.9.2 を使用して、小さな Rails アプリを開発しました。テスト中、私のパソコンでは、パフォーマンスは良好です。Apache と mod_rails を使用して、実稼働用の VPS に配置しましたが、パフォーマンスがひどい場合があります。

production.log の例を次に示します。

2010-11-21 21:49:56 -0500 に XX.XX.XX.XX の GET "/tracker" を開始
FleetsController#index で HTML として処理
レンダリングされた layouts/_stylesheets.html.haml (0.8ms)
レンダリングされた layouts/_header .html.haml (1.0ms)
レンダリングされたレイアウト/_footer.html.haml (0.0ms)
レンダリングされたページ/レイアウト/アプリケーション内の about.html.haml (4.5ms)
15ms で 200 OK を完了 (ビュー: 14.3ms | ActiveRecord: 0.0 MS)

2010-11-21 21:50:02 -0500 に XX.XX.XX.XX の GET "/tracker/" を開始
FleetsController#index で HTML として処理
Rendered layouts/_stylesheets.html.haml (0.7ms)
Rendered layouts/ _header.html.haml (1.1ms)
レンダリングされたレイアウト/_footer.html.haml (0.0ms)
レンダリングされたフリート/index.html.haml (レイアウト/アプリケーション内) (7.8ms) 1901ms
で 200 OK を完了 (ビュー: 7.8ms | ActiveRecord: 1.5ms)

2010-11-21 21:50:06 -0500 に XX.XX.XX.XX の GET "/tracker/fleets/XXXXXXXXX" を開始
FleetsController#show as HTML
パラメータ: {"id"=>"XXXXXXXXX"}
レンダリングされたフリート/_details_inner.html.haml (1.2ms)
レンダリングされたフリート/_details.html.haml (2.1ms)
レンダリングされたフリート/_summary.html.haml (3.5ms)
レンダリングされたフリート/_scouts_inner.html.haml (1.3ms)
レンダリングされたフリート/_scouts.html.haml (3.5ms)
レンダリングされたレポート/_report.html.haml (0.5ms)
レンダリングされた艦隊/_reports.html.haml (3.0ms)
レンダリングされた艦隊/_recon_form.html.haml (39.9ms)
レンダリングされた艦隊/_recon .html.haml (40.8ms)
レンダリングされた users/_user.html.haml (1.2ms)
レンダリングされたフリート/_pilots.html.haml (1.9ms)
レンダリングされたレイアウト/_stylesheets.html.haml (0.5ms)
レンダリングされたレイアウト/_header.html.haml (0.9ms)
レンダリングされたレイアウト/_footer.html.haml (0.0ms)
レンダリングされたフリート/レイアウト/アプリケーション内の show.html.haml (60.2ミリ秒) 495 ミリ秒
で 200 OK を完了 (ビュー: 59.1 ミリ秒 | ActiveRecord: 2.9 ミリ秒)

最初のヒットにはデータベースへのアクセスがありませんでした。2 番目にはデータベース アクセスがありますが、ビューの生成に 7.8 ミリ秒しかかからず、データベースは 1.5 ミリ秒しかかかりませんでしたが、ページ全体はほぼ 2 分間完了しませんでした! これはかなり一般的な例ですが、ページ応答に 14 秒以上かかるログ エントリがいくつかあります。いいえ、これは再起動後の最初のレールのロード中ではありません。

その時間を取っている可能性があるのは何ですか?

1) 私は ActiveRecord の時間レポートを誤解しましたか? それは実際にはコード時間ですが、リアルタイム データベース時間は時間の進行方向です?

2) sqlite を使用しています。(ほとんどの)すべてのページヒットがデータベースの書き込みを引き起こすため、同時実行の問題が発生するため、最終的にはおそらくMySQLに切り替える必要があることを知っています。しかし今のところ、トラフィックはほとんどありません。同時にサイトにいるのは最大でおそらく 15 人です。上記のログの例では、一度に 1 つのヒットしかなく、各ヒットの間に 4 ~ 6 秒あります。私はsqliteがそれを処理できると思います...

3) 共有 VPS を使用しています。これは、VPS 上の他のユーザーが同時に何かを行っていたため、サーバーの速度が低下した可能性があることを意味します。ほとんどの場合、VPS の CPU 負荷は非常に低いですが、不運に見舞われ、その瞬間に何かが起こっていた可能性があります。しかし、私はこれが頻繁に起こるのを見てきたので、それを答えとして買わない.

4) VPS には 512+512MB のメモリしかありません。150MB の空き容量があることを示していますが、メモリの制限に達しているだけで、これはページ スワップか何かである可能性はありますか?

5) ログにいくつかの BusyException も記録されています。database.yml のタイムアウトを (5 秒から) 15 秒に増やして、それが役立つかどうかを確認しました。それ以来、それが行われたかどうかを確認するために実際のテストを行っていません。

何が起こっているのかを実際に教えてくれるほど十分な情報を提供していないことはわかっています。

4

2 に答える 2

2

だから2つのこと..

  1. New Relic を使用して、遅いコードを診断する
  2. ロギングに基づいて、配列操作を行っているか、FleetsController#index でアイテムの大きな配列を返していると思います...アプリケーションコードがそこで何かをしているようです。

http://www.newrelic.com/

それが間違っているように見える場合は、コードを FleetsController#index に投稿してください。しかし、NewRelic は、遅い Web リクエストでサイクルをどこに費やしているかを正確に把握するのに役立ちます。

于 2010-11-22T21:00:56.560 に答える
0

SQLite は同時実行をまったく行いません。おそらくデータベースで接続がブロックされていると思います。実際のクエリは問題ありませんが、別のクエリの実行中に SQLite db ファイルがロックされていると思われます。

MySQL や PostgreSQL などの実際のサーバー データベースに移行する必要があります。

于 2010-11-22T21:43:40.783 に答える