専用のHTTPサーバーを作成する必要があります。このためにepollsycallを使用する予定ですが、複数のプロセッサ/コアを利用したいので、アーキテクチャソリューションを思い付くことができません。ATMの私の考えは次のとおりです。独自のepoll記述子を使用して複数のスレッドを作成し、メインスレッドは接続を受け入れ、それらをスレッドepollに分散します。しかし、もっと良い解決策はありますか？高負荷アーキテクチャで読むことができる本/記事/ガイドはどれですか？私はC10Kの記事しか見たことがありませんが、例へのリンクのほとんどは死んでいます:(そしてこの主題に関する詳細な本はまだありません:(。
回答ありがとうございます。
UPD：具体的に言ってください。資料と例が必要です（nginxは複雑すぎて、複数のシステムをサポートするには複数の抽象化レイヤーがあるため、例ではありません）。
..私の考えは次のとおりです。独自のepoll記述子を使用して複数のスレッドを作成し、メインスレッドは接続を受け入れ、それらをスレッドepollに分散します。
はい、それが現在これを行うための最良の方法であり、Nginxがそれを行う方法です。スレッドの数は、負荷やマシンの物理コアの数に応じて増減できます。
追加のスレッド（物理コアの数を超える）とイベントの間のトレードオフは、レイテンシーとスループットの1つです。スレッドはプリエンプティブに実行できるためレイテンシーが向上しますが、コンテキストの切り替えやスレッドの作成/削除によって発生するオーバーヘッドのためにスループットが犠牲になります。イベントはスループットを向上させますが、実行時間の長いコードによってスレッド全体が停止するという欠点があります。
次善の策は、Apache2がブロッキングスレッドのスレッドプールを使用してそれを行う方法です。ここではイベント処理がないため、実装が簡単になり、プールはスレッドが不必要に作成および破棄されないことを意味しますが、実装しようとしているものやNginxのように適切に実装されたスレッド/非同期ハイブリッドと実際に競合することはできません。
3番目に良いのは、LighttpdやNode.jsのような非同期イベント処理だけです。サーバーで重い処理を行っていない場合は、2番目に良い方法です。ただし、前述のように、1回の長時間実行のwhileループがサーバー全体をブロックします。
テラビットアップリンクがあり、単一のサーバーから10000の同時接続を処理することを計画している場合を除いて、を忘れてくださいepoll。それはただの不必要な非移植性です。pollまたはselect同様に行うでしょう。テラビットアップリンクなどが標準になるまでに、サーバーも十分に高速になるため、まだ必要ないことに注意してくださいepoll。
静的コンテンツを提供するだけの場合は、スレッドも忘れて、Linuxシステムコールを使用してくださいsendfile。これも非標準ですが、少なくとも実際のパフォーマンスには大きなメリットがあります。
また、他の設計上の決定（特に過度の複雑さ）は、サーバーが処理できる負荷の量を大きく左右することに注意してください。たとえば、控えめなシングルスレッドのシングルプロセスthttpdが静的コンテンツのパフォーマンスでApacheとその仲間を吹き飛ばす方法を見てください。私の経験では、従来のcgi動的コンテンツでも同様です。