0

3 番目のパリー API に対していくつかの要求を行うコントローラー メソッドを実装しましたが、これは非常に低速です。さらに、Thinの非同期機能の1 つを利用しました。

# This informs thin that the request will be handled asynchronously
self.response_body = ''
self.status = -1
Thread.new do
  # This will be the response to the client
  env['async.callback'].call('200', {}, "Response body")
end

（それについてのブログ投稿）

ただし、Thin を使用せずにこれを実装できるかどうか、またはより正確に言うと、Apache/Phusionpassenger で実現できるかどうかに興味があります。

提案、ポインタ、リンク、コメント、または回答をお待ちしております。ありがとう

4

1 に答える 1

0

これがパッセンジャー 4 で可能かどうかは不明です。この記事では、イベント モデルをサポートするために完全な再設計を行ったことを発表しました。彼らは Node.js をサポートする計画も持っているので、上記の方法が機能することを期待しています。

しかし、彼らからのこの投稿を見ると、彼らははっきりと言っています：

... ただし、高い I/O 同時実行性をサポートする別の方法があります: マルチスレッド ...

したがって、Rails アプリでのストリーミング サポートを処理するための唯一の重要なオプションとして、マルチスレッド サーバーが残されます。

Rails はイベント プロセス モデル向けには設計されていませんが、マルチスレッド モデルを十分にサポートしています。マルチスレッドの起動は、パッセンジャーエンタープライズで実現できます。

別のオプションは、この問題を別のアプリケーションに抽出することです ( Railscastを参照)。したがって、たとえば、I/O 呼び出しのブロックに最も多くの時間を費やすコントローラーでサードパーティ API を直接呼び出す代わりに、バックラウンド ジョブでこの要求を処理することでこれを解決します。ユーザーはすぐに応答を受け取り、その後、faye メッセージ チャネルに直接サブスクライブします。バックグラウンド ジョブで、サードパーティ コールの準備ができたら、このチャネルで応答を faye に公開します。利益。

于 2014-01-09T08:29:04.643 に答える