Dev Study
← 性能分析の土台
レッスン 1 / 10·約 9 分·第13期 性能分析

速いとは何か — 3つ目の量

リクエストがアプリケーションに届くまで
  1. ブラウザURL入力
  2. DNS名前→IP
  3. ルータ経路選択
  4. ロードバランサ振り分け
  5. Nginx受け口
  6. アプリ処理今ここ
  7. DB保存

第13期の初回です。1件がどう通るかではなく、装置の状態を何の数字で語るかを扱います。

まず結論

レイテンシとスループットの2つだけでは、性能の状態を言い当てられません。スループットが同じでレイテンシが7倍違う状態が、実際に作れます。

区別に要るのは3つ目の量、いま同時に中にいる件数です。この量には決まった呼び名がなく、本教材では並行数と呼びます。

? 読む前に予測

1件の処理時間が一切変わらないサーバに、同時接続だけを4本から32本に増やしました。観測されるレイテンシはどうなるでしょうか。

当てることが目的ではありません。外した予測ほど記憶に残るので、直感で選んでください。

抽象原理

2つの量では状態を言い当てられない

第5週で、パイプラインが速くするのはスループットであって1命令の時間ではないと見ました。今回はその先、2つでは足りないという話です。

観測されるレイテンシは、2つの合計です。

  • 処理そのものの時間 — その1件の仕事にかかる時間
  • 待ちの時間 — 順番が来るまで並んだ時間

外から計った所要時間には両方が入っており、どちらが伸びたかは分かりません。 スループットも助けになりません。枠が埋まったあとは、いくら流し込んでも増えず、増えたぶんが待ちに変わるからです。

要るのは3つ目の量、いま中にいる件数です。

具体実物

この量には決まった呼び名がない

この量を指す規格用語は存在しません。 同じ文書の中でも、近い概念に別々の語が使われています。

RFC 9113(HTTP/2)で近い概念に使われる語表
語           逐語
outstanding  allowed only one request to be outstanding at a time
concurrent   the maximum number of concurrent streams
in-flight    After allowing time for any in-flight stream creation

3つとも RFC 9113 の表現ですが、文脈は別々です(HTTP/1.0 の未完了の要求、ストリーム数の上限、GOAWAY 時に作成途中のストリーム)。queue depth に至っては、本教材が確認した RFC 9110・RFC 9113・iostats.rst のどれにも定義がありません。

本教材では、この量を「並行数」と呼びます。 教材側でつけた名前で、「並行数という規格用語がある」という意味ではありません。

ただし名前が定まらないことと、量が無いことは別です。 iostats.rst はフィールド9をこう説明しています。

Documentation/admin-guide/iostats.rst(抜粋)コマンド出力
Field  9 -- # of I/Os currently in progress (unsigned int)
  The only field that should go to zero.

他は累積値ですが、これだけは現在値で、空になれば0へ戻ります。さらにフィールド11は、I/O の開始・完了・マージのたびに「進行中の I/O 数 × 経過ミリ秒」を足し込むと定義されています。つまりこの量の時間積分です。

カーネルは、名前を与えないまま、この量を積分してまで記録している。

✓ ここまでの確認

「並行数」という語について、最も正確なのはどれですか。

抽象原理

枠が埋まると、入れたぶんは待ちになる

一般化します。処理の枠には数があり、空いている間は流し込んだぶんだけ完了数が増えます。しかし枠が全部埋まると、そこから先に入れたものは処理へ進めず、列に並びます。

このとき3つの量は次のように動きます。

  • スループット — 増えない。枠の数で決まるから
  • レイテンシ — 伸びる。列に並ぶぶんが足される
  • 並行数 — 増える。中にいる件数は増えるから

2つだけでは、「枠が空いた状態」と「列ができた状態」が同じ数字に見えることがあります。 3つ目の量がその差を写します。

3つの量の関係(リトルの法則と呼ばれるもの)は、図解コース「システム性能分析のしくみ」が扱います。

具体実物

処理時間を変えずにレイテンシを7倍にする

本教材の測定環境(Docker Desktop の Linux VM、Linux 6.10.14-linuxkit、aarch64、nproc=10、debian:bookworm-slim)での実験です(測定日 2026-09-18)。

  • サーバはコンテナ内の 127.0.0.1:8099。枠は4つ固定、1件の処理時間は50msに固定
  • クライアントは同コンテナ内から、N本の同時接続 × 各20リクエスト
同時接続数を変えた実測(処理時間は常に50ms固定・max列は省略)コマンド出力
# server: 4 service slots, fixed 50.0 ms service time per request (never varies)
conc=  1 n=  20 wall=  1.07s throughput=   18.7 req/s mean=   53.5ms p50=   52.5 p99=   60.2
conc=  2 n=  40 wall=  1.09s throughput=   36.8 req/s mean=   54.2ms p50=   53.7 p99=   61.3
conc=  4 n=  80 wall=  1.07s throughput=   74.5 req/s mean=   53.6ms p50=   53.3 p99=   57.4
conc=  8 n= 160 wall=  2.11s throughput=   75.8 req/s mean=  102.2ms p50=  104.4 p99=  163.5
conc= 16 n= 320 wall=  4.23s throughput=   75.7 req/s mean=  199.4ms p50=  208.3 p99=  368.0
conc= 32 n= 640 wall=  8.40s throughput=   76.2 req/s mean=  388.9ms p50=  415.3 p99= 1143.0

読み取れるのは3点です。

  1. コードは一度も変わっていません。 処理時間は終始50msです。にもかかわらず観測レイテンシは 53.5ms → 388.9ms へ、約7.3倍になりました。増えたぶんはすべて待ちです。
  2. スループットは conc=4 以降ほぼ動きません(74.5 → 75.8 → 75.7 → 76.2)。4枠を50msで回す計算だと毎秒80件で、実測はその手前でほぼ頭打ちです。差は測定系の費用です。
  3. そして核心 — ハイライトした conc=4 と conc=32 はスループットがほぼ同じ(74.5 と 76.2)です。2つの量だけでは区別できません。 実際には一方が他方より約7倍遅いのに、です。

なお conc=1 の 53.5ms も 50ms ちょうどではなく、差の3.5msは接続確立やソケット往復の費用です。本教材の環境での値で、「処理50msなら53.5ms」という一般則ではありません。

✓ ここまでの確認

スループットが同じ2つの状態を区別するのに、並行数はなぜ役に立つのですか。

⇄ 2つを見比べる
具体例 A

同時接続を増やしたサーバ

処理時間を50msに固定したまま、同時接続だけを増やしました。完了数は枠の数で頭打ちになり、超えたぶんは列に並びます。伸びるのは観測レイテンシだけです。

本教材の測定環境(2026-09-18)表
同時接続   スループット   平均レイテンシ
4         74.5 req/s     53.6 ms
32         76.2 req/s    388.9 ms
具体例 B

CPUのパイプライン(第5週)

段を重ねて複数の命令を同時に流すと、単位時間あたりの完了命令数は増えます。しかし1命令の所要時間は短くならず、区切りの費用でむしろわずかに増えます。

パイプラインで何が変わるか表
見る量            段を重ねると
完了数(スループット)   増える
1命令の所要時間        短くならない

同時接続を増やしたサーバと、段を重ねたCPU。層はまったく違いますが、共通する構造は何でしょうか。

「同時に何本流れているか」と「1本が通り抜ける時間」を別の量として分けてみてください。

抽象原理

3つの量の関係

観測レイテンシの内訳と、3つの量が写すもの
流し込まれた件数同時接続
枠の数で分かれる
処理中枠に入ったぶん
処理の時間
待ち並んでいるぶん
待ちの時間
2つを足すと
観測レイテンシ外から計った時間
2つを数えると
並行数処理中 + 待ち
  • ・スループットは単位時間に何件抜けたかしか写さない
  • ・レイテンシは合計なので、どちらが伸びたかは写さない
  • ・並行数は枠が埋まった後も増え続ける

この章のまとめ

  • 観測レイテンシは「処理の時間」と「待ちの時間」の合計で、数字だけではどちらが伸びたか分からない。
  • スループットは枠の数で頭打ちになり、以降に流し込んだぶんは待ちへ回る。だからスループットが同じでレイテンシが7倍違う状態が実在する(本教材の測定)。
  • 区別に要る3つ目の量が並行数(処理中 + 待ち)。ただし教材側でつけた名前で、規格用語ではない。RFC 9113 の中でも、近い概念に outstanding / concurrent / in-flight と別々の語が使われている。
  • 名前が無いことと量が無いことは別。iostats.rst はフィールド9を「ゼロになるべき唯一のフィールド」として持ち、フィールド11では時間積分まで記録している。
  • ロードアベレージも並行数を数える試みだが、state R に加え state D(ディスクI/O待ち)も数えるので、CPUの混み具合ではない。

自分の現場で確かめる

読んだだけでは身につきません。手元の環境で実際に見てみてください。

環境:

理解度チェック

読んだ直後は「分かった」と感じやすいものです。実際に解いて確かめてください。

問題 1 / 3正解: 0

本教材の測定で、同時接続4本と32本はスループットがほぼ同じ(74.5 req/s と 76.2 req/s)でした。言えるのはどれですか。

用語集(4語)
並行数(本教材の用語)
いま同時に系の中にいる件数。処理中と順番待ちの合計。規格用語が無いため本教材で名前をつけた。文献では近い概念に outstanding / concurrent / in-flight / in progress などの語が使われる。
レイテンシ
1件が入ってから出るまでの時間。観測値は「処理の時間」と「待ち時間」の合計で、外から分離できない。
スループット
単位時間に完了した件数。枠が埋まると頭打ちになり、以降は流し込んでも増えない。
ロードアベレージ
Linux では実行待ち(state R)とディスクI/O待ち(state D)の数を1分・5分・15分で平均した値。CPUの混み具合ではない。

出典(一次ソース)