12

HTTPリクエストの前処理/後処理用にTCPベースのデーモンを構築しています。クライアントはApacheHTTPD（またはIIS）に接続し、カスタムApache/IISモジュールが要求をTCPデーモンに転送してさらに処理します。私のデーモンは、大量のトラフィックを処理するためにスケールアップする必要があります（ただし、スケールアウトはしません）。ほとんどの要求は小さく、短命です。デーモンはC++で構築され、クロスプラットフォームである必要があります。

私は現在、自然にフィットしているように見えるブーストasioライブラリを調べています。ただし、スタックレスコルーチンとスレッドプールパターンのメリットを理解するのに苦労しています。具体的には、HTTPサーバーの例3とHTTPサーバーの例4をここで見ています：http ：//www.boost.org/doc/libs/1_49_0/doc/html/boost_asio/examples.html

すべてのグーグルにもかかわらず、スタックレスコルーチンサーバーのメリットと、マルチコアシステムのスレッドプールサーバーと比較してどのように機能するかを完全に理解することはできません。

私の要件を考えると、2つのうちどちらが最も適切ですか、そしてその理由は何ですか？どうぞ、スタックレスコルーチンのアイデアに関するあなたの答えを「おろそかに」してください。私はまだここで不安定な状況にあります。ありがとう！

編集：議論のための別のランダムな考え/懸念：Boost HTTPサーバーの例＃4は、「スタックレスコルーチンを使用して実装されたシングルスレッドHTTPサーバー」として説明されています。OK、それで完全にシングルスレッドです（親プロセスが子に「フォーク」した後でも？例4のserver.cppを参照してください）...シングルスレッドはマルチコアシステムのボトルネックになりますか？ブロッキング操作を行うと、他のすべてのリクエストの実行が妨げられると思います。これが実際に当てはまる場合、スループットを最大化するために、コルーチンベースの受信データ非同期イベント、内部ブロッキングタスク用のスレッドプール（マルチコアを活用するため）、そして非同期送信およびクローズ接続メカニズムを考えています。繰り返しますが、スケーラビリティは重要です。何かご意見は？

4

2 に答える 2

9

最近、マルチコアマシンでのboost.asioのスケーラビリティを調べました。これまでの主な結論は、オーバーヘッド、ロックの競合、および追加のコンテキストスイッチ（少なくともLinuxでは）が発生するということです。これらのトピックに関する私のブログ投稿のいくつかを参照してください。

また、asioメーリングリストでスレッドを開始して、明らかなものを見逃していないことを確認しました。http：//comments.gmane.org/gmane.comp.lib.boost.asio.user/5133を参照してください。

あなたの主な関心事がパフォーマンスとスケーラビリティであるなら、私は明確な答えがないことを恐れています-あなたはいくつかのプロトタイピングをしてパフォーマンスを見る必要があるかもしれません。

ブロッキング操作がある場合は、必ず複数のスレッドを使用する必要があります。一方、コンテキストの切り替えとロックの競合により、複数のスレッドのパフォーマンスが低下する可能性があります（少なくとも非常に注意する必要があります）。

編集：スタックレスコルーチンのものを明確にするために：非同期APIをシーケンシャル/ブロッキング呼び出しのように見せるための構文上の砂糖です。

于 2012-05-12T21:12:23.227 に答える
0

参照の局所性、CPU命令のキャッシュ、スケジューリングの遅延などの相対的な影響を予測することが難しいため、実際に何が起こるかを確認するために影響を測定する必要があります。

ヒューリスティックな推測が必要な場合は、スタックサイズがSのn個のスレッドを使用すると、各スレッドが実際に使用するスタックスペースの多くが常にnSバイトかかることを考慮してください。それがページの境界を越えてあなたをプッシュする場合、それはパフォーマンスをかなり低下させる可能性があります。

于 2012-05-11T15:03:20.677 に答える