アプリケーションパフォーマンスの分野での平均応答時間は、アプリケーションサーバーがユーザーに要求の結果を返すのにかかる時間です。アプリケーションサーバーの応答時間は通常ミリ秒に近いですが、負荷に応じて時間がかかります。
インターネットの初期の1999年のeコマースサイトの最適なロード時間は8秒でした。2006年度には4秒まで減りました。そして今は3秒を顧客が離れる時間だと話しています。Googleが運用するAdSenseでは、(https://support.google.com/adsense/answer/7450973?hl=ko)は、モバイルページがロードされるのに3秒経過すると、ユーザーの半分以上がサービスを放棄すると調査結果を発表しました。3秒という時間の中にはWebページのレンダリング時間とネットワークが使う時間などが含まれているため、Webアプリケーションが消費する時間は実際にミリ秒に近いです。ただし、実際のサービスに障害が発生すると、Webアプリケーションの平均応答時間はますます長くなります。
負荷が増えてしきい値を超えると、1秒あたりのスループットはもはや増加しなくなります。論理的に考えると、1秒あたりのスループットがもはや増加していない状態でユーザーだけが増えると、TPSと認知時間が定数のように動作するため、応答時間がユーザーに比例して増えます。
[応答時間(Respose Time) = [同時ユーザー数/秒あたりの要求数(TPS)] - 認知時間(Think Time)]
しかし、一般的な状況では、応答時間はミリ秒単位の値ですが、認知時間は3秒から10秒以上の値を持ちます。では、今回はパフォーマンスを分析するストーリーを作りましょう。私たちが英語の文章をハングルに翻訳するウェブサービスを作るとしましょう。私たちは同時ユーザー100人を期待してサービスを作成しています。ここで、サービスの性質上、ユーザーが一度翻訳を要求し、次回要求を送信するのに平均30秒の時間がかかります。最後に、最大応答時間は0.5秒を超えないように設計したいと思います。
このような場合、私たちが目標とする1秒あたりの要求数はサービスを同時に使用する人の要求を時間で割るので、計算式は同時ユーザー数(100人)/(応答時間(0.5秒)+認知時間(30秒))であり 結果値は約3.27になります。
1 秒あたりの要求数 (TPS) = 同時ユーザー数 / [応答時間 (Response Time) + 認知時間 (Think Time)]
このように性能を計算する過程でサービスの処理時間すなわち応答時間は認知時間に比べて非常に少ないため、認知時間が大きくなるほど大きくなるほどTPSに関与する割合が0に収束することになります。
結論として、パフォーマンスを設計する時点で応答時間はあまり重要な問題ではありません。代わりに、認知時間が重要になります。
Webサービスを使用して自分の要求を確認する時間が必要です。このように、前の要求と次の要求の間の時間を認知時間と呼びます。 認知時間は、ユーザーまたはサービスの種類によって異なります。たとえば、システム間の対話には、人が関与するWebサービスの対話に比べて非常に低い認知時間が含まれます。または、ブログサービスと比較して、事前検索サービスの認知時間は非常に短いでしょう。サービスのドメインを分析して認知時間を決定することは非常に重要です。 認知時間を使用して、1分あたりに完了する必要がある要求の数だけでなく、システムがサポートできる同時ユーザーの数を計算できます。
現実では、Webサービスの応答時間は式とは異なります。そのため、多くの先能分析ツールが平均応答時間を示しています。実際のパフォーマンス分析ツールが通知する平均応答時間は、収集サイクル中に収集されたトランザクションの応答時間を合計して平均した値です。
WhaTapのサービスは、5秒間隔で平均応答時間を計算します。応答時間がパフォーマンス指標よりもチューニング指標としての意味を持ちます。たとえば、ユーザーが少ない夜の時間にバッチジョブなどの応答時間が長くなるため、ユーザーが多くの日より平均応答時間が長くなる可能性があります。しかし、実際の性能を上げるための指標として、応答時間は非常に直接的です。TPSに関係なく平均応答時間が長くなる要因がある場合は、周囲の要素と一緒に平均応答時間を調べる必要があります。