平均応答時間とは？求め方とTPS、シンクタイムの関係

平均応答時間とは、アプリケーションサーバーがリクエストを受け取ってから結果を返すまでにかかった時間の平均値です。単位はミリ秒で、性能試験の設計でも日々の監視でも最初に見る指標のひとつです。

ただ、この指標は「小さいほど良い」とだけ覚えておくと本質を見失ってしまいます。性能を設計する段階では応答時間よりシンクタイムのほうが効いてきますし、運用中の監視では性能指標というよりチューニングの手がかりとして考えるほうが正確です。ここでは、計算方法から順に整理して解説します。

ユーザーが待てるのは3秒

インターネット初期の1999年、ECサイトの最適な読み込み時間は8秒とされていました。2006年には4秒まで縮まり、現在は3秒を超えるとユーザーが離れると言われています。Googleも、モバイルページの読み込みに3秒かかると半数以上のユーザーがそのページを離脱するという調査結果を公開しています。

この3秒にはブラウザのレンダリング時間もネットワークの往復時間も含まれます。Webアプリケーション自身が使える時間はそのうちのごく一部で、実際にはミリ秒単位です。逆に言えば、アプリケーション側で障害が起きて応答時間が伸びると、3秒という枠は容易に使い切られてしまいます。

負荷を上げていくと、ある時点からスループット（TPS）はそれ以上伸びなくなります。この状態でユーザー数だけが増えるとどうなるか。TPSとシンクタイムが定数のようにふるまうので、応答時間がユーザー数に比例して伸びていきます。式にすると次のとおりです。

応答時間 = 同時ユーザー数 ÷ TPS - シンクタイム

この式を性能設計の側から使うときは、TPSについて解いた形のほうが便利です。

TPS = 同時ユーザー数 ÷ (応答時間 + シンクタイム)

英文を日本語に翻訳するWebサービスを作ると考えてみます。設計の前提はこうです。

サービスの性質上、ユーザーが一度翻訳をリクエストしてから次のリクエストを送るまでに平均30秒かかるとします。ここで必要なTPSを求めます。

TPS = 100 ÷ (0.5 + 30) = 約3.27

毎秒3.27件を処理できれば、同時に100人が使っても最大応答時間0.5秒という目標を満たせる計算です。

注目したいのは分母の内訳です。30.5秒のうち応答時間は0.5秒しかありません。シンクタイムが大きくなるほど、応答時間がTPSに与える影響はゼロに近づいていきます。つまり性能を設計する時点では、応答時間はそれほど大きな問題になりません。効いてくるのはシンクタイムのほうです。

あるリクエストと次のリクエストのあいだに空く時間をシンクタイム（Think Time）と呼びます。ユーザーが結果を読み、次に何をするか決めるまでの時間です。

シンクタイムはユーザーの種類やサービスの性質で大きく変わります。システム同士が連携する処理は、人が操作するWebサービスに比べてシンクタイムが極端に短くなります。同じ人が相手でも、記事を読むブログサービスと、入力しながら候補を出すサジェスト検索とではまったく違う値になります。

だからこそ、対象サービスのドメインを見てシンクタイムを決める作業が重要になります。この値が決まれば、1分あたりに完了すべきリクエスト数も、システムが支えられる同時ユーザー数も計算できます。

ここまでは設計の話でした。実際に動いているサービスの応答時間は、式のとおりにはなりません。だから多くの性能分析ツールが平均応答時間を表示します。

ツールが出す平均応答時間は、収集周期のあいだに集まったトランザクションの応答時間を合計して平均した値です。WhaTapの場合は5秒間隔で計算しています。

この数値は性能指標というよりチューニング指標として読むほうが正確です。 たとえばユーザーが少ない深夜にバッチ処理が走ると、その時間帯の平均応答時間は日中より長くなることがあります。これは性能が悪化したのではなく、処理の中身が違うだけです。

一方で、性能を上げる作業の手がかりとしては応答時間はきわめて直接的です。TPSが変わっていないのに平均応答時間だけが伸びている区間があれば、そこには理由があります。その場合は応答時間だけを見ず、周辺の指標とあわせて確認してください。

平均応答時間は、リクエストを受けてから結果を返すまでの時間の平均。
求め方は 応答時間 = 同時ユーザー数 ÷ TPS - シンクタイム。設計時は TPS = 同時ユーザー数 ÷ (応答時間 + シンクタイム) の形が使いやすい。
設計段階で効くのはシンクタイム。応答時間の寄与は小さい。
運用中は性能指標ではなくチューニング指標として、周辺指標とあわせて読む。