5

ブックマークレットを使用すると、現在のブラウザー ページのすべての URL が処理のために Rails 3 アプリに送信されます。舞台裏ではTyphoeusを使用して、各 URL が 2XX ステータス コードを返すことを確認しています。現在、RailsサーバーへのAJAXリクエストを介してこのプロセスを開始し、処理して結果を返すまで待ち​​ます。小規模なセットの場合、これは非常に高速ですが、URL の数が非常に多い場合、ユーザーは最大で 10 ~ 15 秒待機する可能性があります。

Delayed Job を使用してユーザーのスレッド外でこれを処理することを検討しましたが、これは適切なユースケースではないようです。ユーザーは結果を確認するために処理が終了するまで待つ必要があり、遅延ジョブはジョブが開始されるまでに最大 5 秒かかる場合があるため、処理ができるだけ早く行われるとは限りません。残念ながら、この場合、この待ち時間は受け入れられません。

理想的には、私が起こるべきだと思うことはこれです:

  • ユーザーがブックマークレットをヒット
  • データは処理のためにサーバーに送信されます
  • スレッドをスピンオフして処理を実行している間に、待機中のページが即座に返されます
  • 待機中のページは、処理の結果について ajax を介して定期的にポーリングし、待機中のページを更新します (例: 「処理された 567 個の URL のうち 4 個...」)。
  • 待機中のページは、準備が整うと結果で更新されます

追加の詳細:

  • Heroku を使用しています (実行時間の長いプロセスは 30 秒後に強制終了されます)
  • ログインユーザーと匿名ユーザーの両方がこの機能を使用できます

これはこれを行う典型的な方法ですか、それともより良い方法はありますか? 処理中にDBを更新する独自のオフスレッド処理をロールする必要がありますか、それともこれに使用できる(そしてHerokuで動作する)遅延ジョブのようなものがありますか? 正しい方向へのプッシュは大歓迎です。

4

1 に答える 1

1

後者のアイデアが最も理にかなっていると思います。各 url-check の処理を​​独自のスレッドにオフロードするだけです (したがって、すべての url チェックが同時に実行されます。これは、順次チェックよりもはるかに高速になるはずです)。それぞれが完了すると、データベースが更新されます (スレッドが互いの書き込みを踏まないようにします)。あなたが言ったように、クライアント側で定期的にポーリングするAJAXエンドポイントは、データベースから完了したプロセスの数を取得して返します。これは十分に単純な方法であり、追加のコンポーネントの必要性を実際に感じることはありません。

于 2010-11-09T21:59:42.607 に答える