現在、多数のスレッドを持つアプリケーションを使用しているため、アプリケーションが非常に大きくなります。各スレッドは長時間実行され、基本的に新しい電子メールのポーリングと処理の無限ループです。各スレッドは 1 つの SSL 接続を保持します。これが、アプリケーションでスレッド化が適切に機能する理由です。
スレッドプーリングを使用したい。最も簡単な方法は、スレッドの数を修正してから、スレッドごとに 10 ユーザーを追加することですが、その時点でも、各ループの処理にかなり時間がかかるため、1 ユーザー / スレッドほど均一に作業のバランスがとれていないようです。さらに、これは実際にはスレッドプールではありません。
私の質問は、ここでの適切な設計パターンは何ですか (上で書いたものよりも確かにインテリジェントであるため)、これをうまく処理する C++ ライブラリはありますか? 私の経験では、Java ユーティリティから設計パターンを作成するのは非常に簡単なので、Java ユーティリティを紹介することも役に立ちます。
1人のユーザー/スレッドがおそらく良い出発点です。ブロックする、またはブロックできるものはすべて、実行中の他のコードによって保持されたり、保持されたりしないように、独自のスレッドで実行する必要があります。電子メールの実際の処理が直接実行される場合は、「実行可能」に配置してJava用語を使用し、スレッドプールに送信できます。Javaの用語はThreadPoolExecutorであり、簡単なものを自分で書くのはそれほど難しいことではありません。コンピューターから最大限の作業を行うには、CPUコアの可能性があるごとに1つのスレッドが必要です。
電子メールごとの作業がそれほど大きくない場合は、スレッドプールをスキップして、リーダースレッドで作業を行う方が簡単で高速な場合があります。あなたはそれを実行するための費用を支払いました、あなたはそれからあなたができるすべての仕事を得るのもよいでしょう。
逆に、電子メールの処理にブロックまたはブロックの取得が含まれる場合は、電子メールごとに新しいスレッドを起動することをお勧めします。スレッドが多くなる可能性がありますが、コンピューターから最大限の作業が得られます。CPU使用率がわずか5％で、電子メールに遅れをとるのは望ましくありません。
問題を解決できるパターンは数多くありますが、決定を下す際の重要なポイントは、パターンの結果を理解することです。ACEのWeb サイトには、 Active Object、Proactor、Reactorなど、適切な同時実行パターンに関するいくつかの論文があります。例は C++ ですが、独自の実装を追求する場合に役立つ図と説明があります。
プロアクターは、洗練されたソリューションを提供するか、別のパターンの基盤として機能します。C++ の実装については、次のboost::asioライブラリをお勧めします。
boost::asio、スレッド プールでの使用方法を示しています。に依存したくない場合はboost、asioライブラリもここで個別にパッケージ化されています。より多くのパターンと情報については、この本を検討してください。
バックエンドのスレッド プール コンシューマとの間に BlockingDeque を配置します。これにより、メール プロデューサーがコンシューマーから分離され、バックエンドでコンシューマーをプールできるようになります。これを見てください：
コモンズのThreadPoolを見てください。Java全体-オープンソースなので、コードを見て、C++に簡単に移植できます
「各ループの処理にかなり長いため、1ユーザー/スレッドほど均一に作業のバランスをとっていないようです」というあなたの声明を本当に理解していませんでした。
いずれにせよ、Active Objectパターンは、あなたのケースではエレガントなものになる可能性があります。他の6パターンの組み合わせです。実際、これにより、エンティティが適切に抽象化されたスレッド プールが実現されます。