20

私は、毎秒 50,000 を超える TCP リクエストを受信、処理、および応答する非常に高性能なエンタープライズ ソフトウェアを構築しています。これは多数の Amazon EC2 サーバーに分散されますが、1 つのサーバーで 1 秒あたりできるだけ多くのリクエストを処理できるようにしたいと考えています (5k/秒で撮影)。Amazon Linux を実行している m1.xlarge インスタンスを使用する可能性が最も高いです。

Boost ASIO を使用して C++ でこのソフトウェアを構築しており、ソケット処理を構築する最も効率的な方法を見つけようとしています。例 ( http://www.boost.org/doc/libs/1_53_0/doc/html/boost_asio/examples.html ) では、「HTTP サーバー 2」をエミュレートする方向に傾いています。従業員。

誰かがそこにある各HTTPサーバーの例の長所/短所を実際に説明できますか?この多くの接続を処理して、追加の洞察(Boostソケット、および/または高スループットEC2構成に関して)を本当に感謝します.

本当にありがとう！

4

2 に答える 2

8

いくつかの提案:

サーバーが何をしようとしているのかについては言及していません。1 秒あたり 50K の新しいリクエストを受け入れて閉じるのか、それとも確立された TCP 接続からのメッセージ (リクエスト) を処理するだけなのか。したがって、私のアドバイスは少し一般的である必要があるかもしれません。

  1. C10K の問題を読む: http://www.kegel.com/c10k.html

  2. ASIO の代わりに epoll をソケット通知ソリューションとして使用することに投資してください。epollは難しくありません。

  3. 一定数のスレッド (2 ～ 8) を使用することを検討してください。これらのスレッド間でソケット接続の負荷を分散するか、スレッドの作業プールを使用して、ソケット スレッドから解析された要求メッセージを処理します。複数のスレッド用に設計しますが、1 つのスレッドのみを使用して開始します。次に、すべてのパフォーマンスの問題を解決します。シングル スレッド ソリューションがうまく機能し、パフォーマンスがピークに達したら、他のスレッドがブロックされている間に複数の操作を処理できるように、スレッド数を増やすことを検討してください。

  4. サーバーのパフォーマンスの問題がソケットの設計外にある可能性が非常に高くなります。継続的にベンチマークを行い、valgrind などのツールを実行して、コードがどこで最も多くの時間を費やしているかを理解します。可能性は高く、それはあなたが最も期待していないところです。たとえば、私のサーバーでは、時間の大部分が小さな一時バッファーのメモリの割り当てと解放に費やされていることがわかりました。私はそれを推測しなかったでしょう。次に、サーバーの設計を変更して、前もってメモリを割り当てたり、スタック メモリを使用したりしました。これにより、リクエストを処理するためにコードでメモリを割り当てる必要がなくなりました。その変更を行うと、パフォーマンスは簡単に 2 倍になりました。

于 2013-06-29T07:51:36.590 に答える
0

ノンブロッキング ソケットを調べて、入力/出力/処理を別々のスレッドに分散することをお勧めします。おそらく、1000接続ごとに3つの新しい入力/出力/処理スレッドを作成しますか?

それが役立つことを願っています。

于 2013-06-29T06:20:25.117 に答える