0

サーバーを設計するときは、次の 2 つのアプローチを検討しています。

  1. 非同期 (選択ベース) アプローチにより、バックエンド rpc を単一のスレッドで並列化できます。

  2. 各バックエンド rpc がスレッド プールの別のスレッドで処理される同期アプローチ。

トレードオフがあります。1 つはパフォーマンスが向上し、2 はコードの複雑さが軽減されます。マシンがマルチコアおよび 64 ビットに移行する現在、1 は本当に重要ですか?

4

4 に答える 4

0

これは関連する読み物です(一種の少数派の報告です):

http://www.usenix.org/events/hotos03/tech/full_papers/vonbehren/vonbehren.pdf

これも良いリソースです:

http://www.kegel.com/c10k.html

マルチコアアーキテクチャの有用性を最大化するために、ある意味で2つのアプローチを組み合わせることができることを覚えておいてください。サーバー( "Krumpets here!";)が分割可能であると仮定すると、つまり、同じマシン上でサーバーの複数のインスタンスを実行できます。selectを使用してサーバーを作成し、CPUコアごとにサーバーの1つのインスタンスを実行します。

于 2009-05-08T12:35:59.510 に答える
0

サーバー要件の詳細を知らなければ、どのアプローチパフォーマンスを向上させ、コードの複雑さを軽減するかを判断するのは困難です。

面白いことに、実際のサーバー設計では通常、パフォーマンスとシンプルさが両立します (ただし、単純化したデザインを思いつくのは難しいことです)。select/poll だけでは、自動的にパフォーマンスが向上するわけではありません。また、スレッド プールによってコードの複雑さが軽減されることはありません。

あなたの質問に答えるには: 1 まだ重要です。非同期設計はマルチプロセス マシンにうまくスケーリングしませんが、それはサーバーが 1 つのプロセスで実行されている場合にのみ当てはまります。サーバーがマルチプロセス マシン上で複数のプロセスを生成するように設計されている場合はどうなるでしょうか。異なるユーザー アカウントで異なるプロセスを実行し、異なるセキュリティ設定を使用できます。仮想マシンはどうですか?プロセスごとに 1 つのスレッドがあるからといって、マルチコア マシンを利用できないわけではありません。

しかし、最後に async select() に基づく実際のサーバー設計を見たのはいつだったか思い出せません。私が大学にいたときの教科書にはあったかもしれませんが、実際の生産システムにはありませんでした。

于 2009-05-07T04:30:03.860 に答える