3秒でわかる
処理を頼んでから最初の応答が返るまでの待ち時間。単位時間あたりの処理量を示すスループットとは別物で、体感速度を決めるのはこちらです。
30秒図解
もう少し詳しく
どういうものか
レイテンシは、何かを依頼してから応答が返り始めるまでの待ち時間です。単位はミリ秒 (ms) やマイクロ秒 (us) を使います。Web なら「リンクを押してから最初のバイトが届くまで」、DB なら「クエリを投げてから 1 行目が返るまで」、ディスクなら「読み取り命令から先頭データが来るまで」を指します。よく水道管にたとえられ、レイテンシは管の長さ、スループットは管の太さにあたります。太い管でも長ければ、水が出始めるまでは待たされます。
なぜ必要か
サーバの性能を語るとき、1 秒あたり何件さばけるか (スループット) だけを見ると、体感速度を取り違えます。1 秒に 1 万件処理できるサーバでも、1 件あたり 800 ミリ秒待たされるなら、利用者にとっては遅いサービスです。逆にレイテンシが 20 ミリ秒でも、同時に 10 件しかさばけないなら混雑時に行列ができます。この 2 つは独立して悪化するので、別々に測る必要があります。
もうひとつ重要なのは平均値で語らないことです。平均 100 ミリ秒でも、100 回に 1 回だけ 3 秒かかるなら、1 画面で 50 回 API を呼ぶ構成では利用者の半数が 3 秒待ちを踏みます。p95、p99 といった上位パーセンタイルで見るのが実務の作法です。監視ツールが平均しか出していないなら、そこは実態を隠している可能性があります。
具体例
東京の<a href="/glossary/browser" class="text-primary font-medium underline underline-offset-2 hover:text-primary-dark">ブラウザ</a> → 東京のサーバ 約 5 ms
東京のブラウザ → 米国西海岸のサーバ 約 110 ms
<a href="/glossary/memory" class="text-primary font-medium underline underline-offset-2 hover:text-primary-dark">メモリ</a>読み出し 約 100 ns
SSD 読み出し 約 100 us# 往復の遅延を測る
ping -c 5 example.com
# 最初のバイトが届くまでの時間を測る
<a href="/glossary/curl" class="text-primary font-medium underline underline-offset-2 hover:text-primary-dark">curl</a> -o /dev/null -s -w "ttfb=%{time_starttransfer}\n" https://example.comつまずきやすいところ
多くの遅さは、1 回の処理が重いのではなく往復回数が多いことで起きます。一覧 100 件それぞれについて詳細 API を呼ぶ設計は、1 回 50 ミリ秒でも合計 5 秒です。この N+1 の形は、SQL でもフロントの API 呼び出しでも同じように現れます。回線を速くしても往復回数は減らないため、まとめて 1 回で取る形に直すのが先です。
もうひとつの誤解は、キャッシュを入れれば必ず速くなるという思い込みです。キャッシュが効くのは同じ結果を何度も返す場合だけで、利用者ごとに違う結果を返す画面では、キャッシュの確認そのものが往復を 1 回増やして遅くなることがあります。どこに時間が使われているかは、推測せずブラウザの開発者ツールのネットワークタブや APM のトレースで区間ごとに測ります。
覚え方
レイテンシは待ち時間、スループットは処理量。行列に並ぶ時間と、レジが 1 分に何人さばくかの違いだと考えると混ざりません。