3

セルロイドを使用した JRuby アプリケーションがあります。Zeromq ソケットを介してリクエストを受信し、JSON 文字列で応答します。

したがって、私のアプリケーションには 2 つのアクターがあり、1 つはリクエストを処理するため、もう 1 つは応答を送信するためです (Zeromq のプッシュ ソケット)。アプリケーションは約 30 リクエスト/秒のレートでリクエストを受け取ります。将来的には 1000 リクエスト/秒になるでしょう。ただし、1 秒あたりのリクエスト数が増えると、処理に時間がかかります。より多くの CPU を使用し始めます。

受信したリクエストごとに、遅延ブロック内で処理しています。

defer {
  response = ResponseHandler.new(socket,message).start
  send_response(response)
}

1 秒あたり 20 リクエストの場合、遅延なく正常に動作します。サーバーは 15Gb RAM と 4 コアの構成です。Postgres DB と Redis DB にも接続します。しかし、それはここでは問題ではないようです。

これが私が持っている基本的な構造です。主な俳優サービスがあります。

supervisor = Service.supervise

これにより、10 個のプールを持つ PushSock アクターのインスタンスが内部的に作成されます。

@pushsocket_actor = PushSock.pool(size: 10)

上記の defer ブロックの send_response メソッドは、pushsocket アクターを呼び出します。defer ブロックでは、ResponseHandler は Actor ではありません。

そのため、Service Actor ではプールを使用していません。

4

1 に答える 1

2

プールを使用します。

現在、新しいスレッドを生成し続ける内部スレッド プールを使用しています。代わりに、アクターのプールを作成し、次に ... を使用して呼び出しasyncます。これにより、一度に実行されるタスクの数が実際に減少します。リクエストを受け取るだけでなく、全速力で処理を行うため、応答時間が短縮されます。

ただし、リソース要件については現実的である必要があります。リクエストごとにいくら必要か知っていますか？それに基づいてアクターの戦略を立てる必要があります。

アクターを多すぎたり少なすぎたりしないでください。現在、使用しているスレッドが多すぎると思われます。これは、現実的なサイズのプールで使用した場合defer {}のように、使用しても制限が設定されないためです。async

于 2016-04-07T16:42:23.263 に答える