スループット（Throughput）

スループットとは、システムが単位時間あたりにこなす仕事量のことです。API なら 1 秒あたりのリクエスト数（RPS）、決済システムなら 1 秒あたりのトランザクション数（TPS）、キューのコンシューマーなら 1 秒あたりのメッセージ数です。スループットは処理能力を測るものであり、一方のレイテンシは個々の仕事にどれだけ時間がかかるかを測ります。性能を説明するには、この 2 つにエラー率を加えた 3 つが必要です。

スループット、レイテンシ、同時実行数の関係

定常状態のシステムでは、リトルの法則（Little’s Law）がこの 3 つを結びつけます。

concurrent requests in flight = throughput × average response time

Example: 200 requests/second × 0.25 seconds = 50 requests in flight

操作の合間に一時停止する仮想ユーザーの場合、思考時間（think time）がサイクルに加わります。スループット ≈ ユーザー数 ÷（応答時間 + 思考時間）です。したがって、応答時間 0.5 秒、思考時間 4.5 秒のユーザー 100 人が生み出すのは、毎秒 100 リクエストではなく約 20 リクエストです。「1,000 ユーザーでテストした」という言葉は、思考時間とその結果のリクエストレートも示さない限りほとんど意味を持たないのはこのためです。

負荷が増えるとスループットはどうなるか

負荷が増えると、最初はスループットもそれに比例して上がります。ある時点でリソース（CPU、接続プール、シングルスレッドのコンポーネント）が飽和すると、スループットは頭打ちになり、レイテンシが急上昇します。さらに負荷をかけると、システムが待ち行列、リトライ、タイムアウトに労力を費やすため、スループットは実際に低下することもあります。この頭打ちの点を見つけることがストレステストの主な成果であり、それが実質的な処理能力を決めます。

テストのコツ

• 目標はレートとレイテンシの組み合わせで示す。 「500 RPS で p95 が 300 ms 未満、エラー率 1% 未満」ならテストできます。「高トラフィックに耐える」ではテストできません。
• 成功した仕事だけを数える。 2,000 RPS で応答していても半分が 500 エラーなら、有用な仕事を 2,000 RPS こなしているとは言えません。
• 可能なら到着レート方式の負荷を使う。 一定のリクエストレートを生成すれば、システムがそれを維持できるかが直接わかります。ユーザー数を固定したプールでは、レスポンスが遅くなるにつれて送るリクエストが知らないうちに減ってしまいます。
• 負荷生成マシンを確認する。 テストを実行しているマシンの CPU が 100% なら、測ったのはシステムではなく負荷生成マシンのスループットです。
• レート制限に注意する。 429 を返すゲートウェイは測定されるスループットに上限をかけます。テストしているのがリミッターなのか、その背後のサービスなのかを決めておきましょう。