0

N多数のクライアント ( = 10 ～ 100)にサービスを提供するネットワーク製品のバックエンドを開発しています。各接続には、2 つの定期的なタスク、ハートビート、および SSH を介したテレメトリのダウンロードがそれぞれHHz で必要です。フロントエンドから来る別の種類の追加イベントもあります。すべてのタスクの性質上、select各接続のソケットで待機中の確実な部分があります。これにより、OS は、応答を待っている間に他のクライアントにサービスを提供するためにスレッド間を頻繁に切り替えることができます。

私の最初の実装では、接続ごとに 3 つのスレッド (ハートビート、テレメトリー、エクストラ) を作成し、それぞれが単一の条件変数を待機しています。ワークキューは、タイマーとフロントエンドからのコマンドを使用して、上記の定期的なイベントで満たされます。

ここでいくつか質問があります。

  1. ワーカー スレッド プールのアプローチを Intel TBB タスクに切り替えるのは良い考えでしょうか? もしそうなら、スレッドのどの値に初期化する必要がありますtbb::task_scheduler_initか?

  2. 300 スレッドが条件変数 ( 1 秒あたりsignaledN * H * 3回) を待機している現在のアプローチでは、スケーラビリティのボトルネックになる可能性があります (特に を呼び出す側でsignal)。タスクごとにワーカーを 1 つだけ起動するためのより良い方法はありますか?

  3. ワーカー スレッドのウェイクは TBB でどのように実装されていますか?

ご提案いただきありがとうございます。

4

1 に答える 1

1

TBB への切り替えが適切なアプローチであるかどうかを判断するのは困難です。パフォーマンス要件と、現在の実装のパフォーマンス数値は? 現在のソリューションで十分な場合は、おそらく切り替える価値はありません。

両方 (現在の impl と TBB) を比較して、どちらがより優れたパフォーマンスを発揮するかを知りたい場合は、各実装に対して"トレーサー弾" ( The Pragmatic Programmerという本から) と呼ばれるものを実行し、結果を比較することができます。簡単に言えば、それぞれの縮小プロトタイプを作成し、結果を比較します。

この回答で述べたように、通常、変更しようとしているものが改善されるという具体的な証拠なしにパフォーマンスの改善を試みることはお勧めできません。

そのすべてに加えて、スレッド数が CPU コア数の関数であるスレッド プールを作成することを検討できます (コアあたり 1 または 1.5 スレッドの係数である可能性があります)。スレッドは共通のワーク キューからタスクを取得します。 . タスクには、ハートビート、テレメトリ、エクストラの 3 種類があります。これにより、多数のスレッドを使用する場合のコンテキスト切り替えによる悪影響が軽減されます。

于 2012-11-05T10:59:41.043 に答える