スループットとレスポンスタイムの関係（応用情報視点）

性能の話になると、
「スループット」と「レスポンスタイム」という指標が出てきます。

応用情報技術者試験では、
この2つを別物として理解しているか、
そして同時に成り立たない場合があることを
理解しているかが問われます。

この回では、
スループットとレスポンスタイムの関係を、
応用情報視点で整理します。

スループットとは何か

スループットは、
一定時間あたりに処理できる量を表す指標です。

• 1秒間に何件処理できるか
• 1時間に何件完了するか

といった形で評価されます。

応用情報では、
全体の処理能力を見る指標として扱われます。

レスポンスタイムとは何か

レスポンスタイムは、
要求してから結果が返ってくるまでの時間です。

• ボタンを押してから画面が表示されるまで
• リクエスト送信から応答受信まで

利用者の体感に直結する指標です。

なぜ両立しないことがあるのか

スループットを最大化しようとすると、

• 処理をまとめて実行する
• 待ち行列を長くする

といった設計になりがちです。

その結果、
1件あたりの待ち時間（レスポンス）が悪化
することがあります。

逆に、
レスポンスタイムを最優先すると、
全体の処理量が伸びない場合もあります。

応用情報での典型的な出題意図

午後問題では、

• 処理件数は十分
• しかし利用者の不満が大きい

あるいは、

• 応答は速い
• しかし全体が詰まっている

といった状況が描かれます。

ここで、
どちらの指標を改善すべきかを
見抜けるかが問われます。

実務での考え方

実務では、

• オンライン処理：レスポンスタイム重視
• バッチ処理：スループット重視

といったように、
用途によって優先順位が変わります。

応用情報は、
その使い分けを
設計判断として理解しているかを見ています。

まとめ

• スループットは量の指標
• レスポンスタイムは待ち時間の指標
• 応用情報は優先順位の判断を問う

性能問題を見るときは、
「誰のための性能か」
を先に考えることが重要です。

次回予告

次回は、
「なぜ速いサーバーを買っても遅くなるのか」
を扱います。

性能劣化の本質に進みます。