11

次の 2 つの図は、非イベント駆動型 Web サーバー (IIS + C# など) と比較して、イベント駆動型 Web サーバー (Node.js + JavaScript など) でスレッドがどのように機能するかについての私の理解です。

従来の (非イベント駆動型) Web サーバー

ここに画像の説明を入力

この図から、従来の Web サーバーでは、3 つの長時間実行される操作を実行するために使用されるスレッドの数が、イベント駆動型の Web サーバーよりも多いことがわかります (3 対 1)。

「従来のWebサーバー」のカウントは正しい(3)と思いますが、イベント駆動型のもの(1)については疑問に思います。ここに私の質問があります:

  1. イベント ドリブン シナリオで 1 つのスレッドのみが使用されたと想定するのは正しいですか? それは正しくありません。I/O タスクを処理するために何かが作成されているに違いありません。右?

  2. イベント サーバーはどのように I/O を処理しましたか? I/O がデータベースから読み取ることであったとしましょう。データベースへの接続ジョブを引き渡すために、Web サーバーがスレッドを作成する必要があったのではないでしょうか? 右?

  3. イベント駆動型 Web サーバーが実際に I/O を処理するスレッドを作成した場合、どこで利益が得られるのでしょうか?

  4. 私の混乱の考えられる説明は、従来のシナリオとイベント駆動型の両方のシナリオで、実際には I/O を処理するために 3 つの個別のスレッドが作成された(図には示されていません) ということですが、違いは実際にはスレッドの数にあります。 I / Oスレッドではなく、Webサーバー自体。それは正確ですか?

4

2 に答える 2

6
  1. ノードは IO にスレッドを使用する場合があります。JS コードは単一のスレッドで実行されますが、すべての IO 要求は並列スレッドで実行されます。一部の JS コードを並列スレッドで実行する場合は、thread-a-gogo またはその動作を緩和する他のパッケージを使用します。

  2. と同様1.に、スレッドは IO 操作のために Node によって作成されます。

  3. 必要でない限り、スレッド化を処理する必要はありません。より簡単に開発できます。少なくともそれが私の見解です。

  4. ノード アプリケーションは、別の Web サーバーのように実行するようにコーディングできます。通常、JS コードは単一のスレッドで実行されますが、別の方法で動作させる方法があります。

個人的には、スレッドを試してみたい場合は、threads-a-gogo をお勧めします (パッケージ名はわかりにくいですが、使いやすいです)。それはより速いです。ノードは複数のプロセスもサポートしています。それを試してみたい場合は、完全に別のプロセスを実行することもできます。

于 2013-01-07T11:19:58.173 に答える
1

NodeJS を想像する最良の方法は、メッセージをやり取りするために無限の数のハト (I/O) が利用できる車輪の中で走っている猛烈なリス (つまりスレッド) のようなものです。

ノードの I/O は「フリー」です。リスは接続を確立してハトを送り出すように機能し、ハトがデータを取得している間、ハトが戻ってきたときにのみデータを処理して、他のことを行うことができます。

悪いコードを書くと、リスがそれぞれのハトを待たせることになります。

したがって、常にノンブロッキング I/O コードを記述してください。

ハトに戻ってくることを約束させることができれば ;)

Promise とジェネレーターは、おそらくこれに対する最善のアプローチです。

ただし、ノード クラスターを使用してマスター リスを確立し、マスター リスが作業を行うために見つけた CPU の数に基づいて子リスを生成することができます。

これが役立つことを願っており、車のアナロジーが完全に欠如していることに注意してください.

于 2016-03-29T15:34:22.310 に答える