I/O と並行処理 — 待っている間に、何をするか

What — 待っている時間と、計算している時間は違う

サーバーの処理時間は、性質の違う2つに分かれます。

• I/O 待ち — DB の応答、外部 API の応答、ファイルの読み書き。待っている間、CPU は空いている
• 計算（CPU） — 画像の変換、暗号の処理、大きな JSON の解析、複雑な正規表現。その間、CPU を占有する

普通の Web の処理は、ほとんどが I/O 待ちです。

GET /products/42 の内訳（合計 85ms）
  DB のクエリ         5ms   ← 待っている。CPU は空き
  外部の在庫 API     70ms   ← 待っている。CPU は空き
  JSON の組み立て     3ms   ← 計算
  そのほか            7ms

85ms のうち、CPU を使っているのは 10ms ほどです。残りの 75ms は待っているだけなので、その間に別のリクエストを進められます。これが「1台で同時に何百ものリクエストを捌ける」理由です。

I/O バウンド

処理時間の大半が待ち時間である状態。同時に走らせる数を増やすと、捌ける量が増える。

CPU バウンド

処理時間の大半が計算である状態。同時に走らせる数を増やしても、捌ける量は増えない。

スループット

単位時間あたりに捌ける件数。

レイテンシ

1件あたりにかかる時間。

待ち方には、2つのやり方がある

1リクエスト = 1スレッド（Java, Ruby, PHP など）

Why — なぜ無関係な API まで遅くなったのか

冒頭のサービスはイベントループのモデルでした。1本のスレッドが、順番に仕事を進めます。

待つ処理なら、待ちに入った時点で次の仕事へ移れます。ところが計算している間は、移れません。その 0.4 秒のあいだ、他のリクエストは1件も進みません。

CPU バウンドか、I/O バウンドかの見分け方

どちらかで、打つ手がまったく変わります。同時に走らせる数を増やしてみると分かります。

冒頭の事故は後者でした。同時実行数を増やしても、CPU は増えません。 押し込む量が増えるだけで、1件あたりが遅くなります（data/connection-pool の「DB は接続の数だけ速くならない」と同じ形）。

スレッドモデルなら安全、ではない

スレッドごとに処理するモデルでは、重い計算を書いても他のリクエストのスレッドは動き続けます。イベントループのように全員が止まることはありません。

代わりに、別の形で詰まります。

• スレッドの数が上限。 計算がスレッドを長く占有すると、空きスレッドが減り、新しいリクエストが待たされる
• CPU の取り合い。 コア数を超えるスレッドが同時に計算すると、切り替えの費用で全体が遅くなる

どちらのモデルでも、CPU の総量は増えません。 違うのは、詰まり方が「全員が同時に止まる」か「じわじわ遅くなる」かです。イベントループのほうが症状が派手で、気づきやすいとも言えます。

演習 — まず自分で判断する

解説を読む前に、まず自分で判断してみてください。ここで一度詰まっておくと、 次の節の判断軸が「なるほど」ではなく「そう来たか」に変わります。