Node.jsデザインパターン 第2版

1.2

 リアクタパターン

5

の操作が伴う場合は

1

分以上になる場合もあります。

次の擬似コードは典型的なブロッキング

I/O

の例で、ソケットからデータを読み込むものです。

data = socket.read(); //

データを受信するまで待つ

print(data); //

データが入手できた

ウェブサーバがブロッキング

I/O

を用いて実装されていたらどうなるでしょうか。ソケットの

I/O

は

ほかの接続の処理をブロックしてしまい、複数の接

コネクション

続を同一スレッドでさばくことはできません。この

ようなウェブサーバにおいて複数の接続を同時にさばくには、新しいリクエストが来るたびに新しい

スレッド（あるいはプロセス）を起動する（あるいはプールしてあるものを再利用する）ことになります。

複数のスレッドでリクエストを処理すれば、ひとつのスレッドが

I/O

処理待ちの状態になっていても、

他のリクエストを受け付けることができ

ます。

図1-1にこのような処理の様子を示します。各スレッドは接続先からデータを受信するたびに、

I/O

処理待ちの状態（アイドル状態）になります。この図は各スレッドのアイドル時間がいかに長いかを表

しています。また、ネットワークだけでなく、データベースやファイルシステムの

I/O

も考慮すると、

スレッドのアイドル時間はさらに長くなります。スレッドが消費するメモリや「コンテキストスイッチ」

のコストを考えると、「接続ごとにスレッドを実行し、しかもほとんどの時間アイドル状態のまま」とい

うのは効率がよいとは