1

Ruby Grape を使用して API を作成していますが、次の問題に直面しています。新しい GET リクエストがあると、大量のデータが要求され、時間がかかります。その間、Reactor はブロックされ、リクエストが完了するまで新しいリクエストを処理できません。コードは非常に単純です。

class API < Grape::API
  resource :users do
    get do
      get_users()
    end
  end
end

get_users は TCP で別のシステムに接続し、JSON に変換された大量のデータを取得します。これは、サードパーティの gem を使用して行われます。この種の状況を処理するための最良の選択肢は何でしょうか?

4

2 に答える 2

0

私は2つのオプションを考えています：

  1. 同時リクエストを処理するのに十分なワーカーでパッセンジャー/ユニコーンなどをセットアップします。
  2. これで十分でない場合: API ロジックを再作成して、長い操作が最大 2 つの呼び出しに分割されるようにします。

また、適切であれば、 get_users() の結果をキャッシュできます

于 2013-03-11T19:28:02.837 に答える
0

アプリケーションが長時間のブロッキング I/O 操作を実行している。このような種類のワークロードを適切に処理するには、システムが高い I/O 同時実行性をサポートする必要があります。

Phusion Passenger オープン ソースや Unicorn などの従来のシングルスレッド マルチプロセス システムは、この種のワークロードには適していません。それらが処理できる同時実行の量は、プロセスの数によって制限されます。この問題は、Unicorn の哲学ページの「Just Worse in Some Cases」セクション、またはPhusion Passenger の同時実行のチューニングに関する Phusion の最近の記事に記載されています。

Thin は理論上、イベント I/O モデルにより高い I/O 同時実行性を処理できますが、これを利用するには、アプリケーションとフレームワークを明示的に作成する必要があります。これを行うフレームワークはほとんどありません。Rails も Sinatra も、イベント化された I/O をサポートしていません。Cramp はそれをサポートしており、名前を忘れた別の新しいイベント フレームワークがありました。しかし、Grape はイベント I/O をサポートしていないようです。

解決策は、マルチスレッド対応のアプリケーション サーバーに切り替えることです。これは、高い I/O 同時実行もサポートできます。そのようなアプリケーション サーバーの 1 つがPhusion Passenger 4 Enterpriseで、ハイブリッド マルチスレッド/マルチプロセス モデルをサポートします。マルチスレッドは同時実行性であり、マルチプロセスは安定性と複数の CPU コアを活用するためのものです。Phusion ブログでは、さまざまなワークロードの最適な同時実行設定について説明しています。

于 2013-03-14T11:12:36.033 に答える