より多くのリクエスト/秒の処理の遅延

Question

私はセルロイドを使用するJRubyアプリケーションを持っています。 Zeromqソケットを介してリクエストを受け取り、JSON文字列で応答します。

私のアプリケーションにはリクエストを処理する人とレスポンスを送信する人が2人います（ZeromqのPush socket）。 アプリケーションは約30要求/秒の速度で要求を受け取りますが、将来は1000 /秒といっそう多くなります。しかし、1秒あたりのリクエスト数が増えると、処理に時間がかかります。より多くのCPUを使用し始めます。

受信したリクエストごとに、その内部ブロックを処理しています。

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

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

は、ここで私が持っている基本的な構造で、 が、これは内部的に10のプールでPushSock俳優のインスタンスを作成します

supervisor = Service.supervise 

、メインの俳優・サービスがあります。

@pushsocket_actor = PushSock.pool(size: 10) 

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

サービス俳優の場合、私はプールを使用していません。

Answer 1

プールを使用します。

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

リソース要件については現実的である必要があります。リクエストごとにどれだけ必要なのか分かりますか？それに基づいてあなたの俳優戦略を計画する必要があります。

俳優を多すぎたり少なすぎたりしないでください。現時点では、defer {}を使用するとasyncのような制限はありませんが、現実的なサイズのプールで使用すると、疑わしいスレッドが多すぎます。