1

長い MySQL クエリを含む長いバックエンド ジョブを定期的に実行する必要があり、完了するまでに数時間かかります。このジョブをスケジュールするために Delayed Job gem をセットアップしました。

このプロセスが実行されている場合:

  • このジョブは Rails フロントエンド サーバーの速度を低下させますか (つまり、単純なユーザーの要求に応答するのに時間がかかりますか)?
  • 大量の計算が行われる場所: 私の Rails サーバーか、それとも MySQL サーバーか?
  • スケジュールされたジョブによって MySQL サーバーが占有され、誰も同時に MySQL にアクセスできなくなりますか?

ありがとうございました。

4

2 に答える 2

1

あなたの質問への答えは次のとおりです。

  1. タスクがプロセッサを集中的に使用する場合、Rails サーバーの速度が低下する可能性があります。DJ ワーカーがフロント エンド ボックスに影響を与えることが懸念される場合は、共有 DB にアクセスできる別のボックスに DJ ワーカーを移動します。ワーカー ボックスにはプロジェクトのセットアップが必要ですが、ページを提供しているボックスと同じである必要はありません。

  2. これは、タスクの書き方に完全に依存します。通常、Rails アプリは単純な選択 / 挿入 / 更新 / 削除を行います。実際の計算はレールで行われます。ただし、複雑な結合を伴う select ステートメントを指定したり、DB の関数を利用したりすることはできます。これにより、複雑なフィールドの計算を DB にオフロードできます。

  3. これは、DB が受け入れるように構成されている接続の数に依存します。通常、本番レベルのサーバーでは、クエリのサイズから問題が発生することはありません。ただし、アクティブな接続の数と、許可されている接続の数を考慮する必要があります。各 Rails インスタンスは、DJ の各ワーカーと同様に接続としてカウントされます。

いずれの場合も、実際のパフォーマンスはいくつかの要因に依存します。作成している接続の数、ワーカーと DB の間で送信しているデータの量。どこで仕事をしていますか。

于 2012-04-15T23:21:58.460 に答える
1

Rails サーバーが mysql サーバーと同じマシン上にある場合、何らかの影響があります。しかし、お使いの OS と MySQL を組み合わせることで、他に多くの介入をしなくても影響を最小限に抑えることができます。展開方法に応じて、いつでも「nice」コマンドを利用して、遅延ジョブの優先度を下げ、サイトの応答性への影響を最小限に抑えることができます。

于 2012-04-15T23:22:05.157 に答える