パフォーマンス - マルチスレッドまたはマルチプロセスアプリケーション

Question

Linux上で高度にネットワークを使用するサーバーアプリケーションを開発するには、どのようなアーキテクチャが適していますか？このアプリは通常、複数のコア（仮想または物理）を搭載したマシン上で動作するという考えがあります。パフォーマンスが重要な基準であることを考慮すると、マルチスレッドアプリケーションやマルチプロセス設計の方が良いでしょうか？私は、複数のプロセスからそのようなリソースにアクセスするためのリソースの共有と同期がプログラミングオーバーヘッドの多くであることを知っていますが、前述したように全体的なパフォーマンスが重要な要件であるため、プログラミング言語はC/C++になります。

マルチスレッドアプリケーション（シングルプロセス）であっても、複数のコアを利用して独立して別のコアで各スレッドを実行できると聞いています（同期の問題がない限り）。このスケジューリングはカーネルによって行われます。もしそうなら、マルチスレッドアプリケーションとマルチプロセスアプリケーションの間にはパフォーマンスに大きな違いはありませんか？ Nginxはマルチプロセスアーキテクチャを使用していますが、実際には高速ですが、マルチスレッドアプリケーションで同じパフォーマンスを得ることができますか？

ありがとうございました。

Answer 1

Linux上のプロセスとスレッドはお互いに非常に似ています。主な相違点は、仮想メモリ全体が共有され、信号処理のような特定のことが異なることです。

これは、スレッド間の安価なコンテキスト切り替え（コストのかかるMMUリロードなどの必要性なし）を可能にしますが、速度の違い（特にスレッドの作成外）は必ずしも大きくはありません。非常にネットワーク集約型アプリケーションを設計するための

は、基本的にのみソリューションがイベント化アーキテクチャを使用することである（そうでなければ、プロセス/スレッドの膨大な量でシステムを行き詰まらし、実際に実行しているよりも、自分の管理に多くの時間を費やしていますワークコード）では、ソケット上のI/Oに反応し、どのソケットがアクティビティを示すかに基づいて適切な操作を行います。このような状況に直面している問題について

有名な過去記事はhttp://www.kegel.com/c10k.htmlから入手「C10k問題」、ある - 日付ビットであるにもかかわらず、それは非常に良い紹介ですので、それは、異なるI/Oのアプローチを説明します。

リアクタのようなデザインに深く入る前に注意してください。扱いにくく複雑なものになる可能性があります。そのため、より抽象性の高いライブラリ/言語を使用できない場合があります（ErlangはこのGoのようなコルーチンを持つ言語も便利です）。

Answer 2

あなたのスレッドが互いに独立して仕事をしているのであれば、Linuxでは複数のプロセスを使わずに済む理由があります。複数のプロセスでは、各プロセスが独自のメモリ空間を持つため、メモリ使用量が増加しますが、独立スレッド間でメモリ空間を共有することは悪い決定です。プロセスとスレッドの間のコンテキストの切り替えは、スレッドというよりはプロセスのほうがよく行われますが、アーキテクチャは少し異なり、コードにも依存します。プロセスは、ロックやミューテックスでシリアル化されないように安全です。 Linuxでプロセスを管理して対話するのがより簡単です。あなたが興味をそそるかもしれない良い文書がここにあります（http://elinux.org/images/1/1c/Ben-Yossef-GoodBadUgly.pdf）。