Http/html で作成した同じスクリプトを TruClient と比較してみます。どちらのシナリオでも、思考時間/待機時間、仮想ユーザー数、ペーシングは同じです。
各トランザクションの時間がほぼ同じである可能性はありますが、通過したトランザクションの総数に関しては非常に異なりますか?
事前にタイ
Http/html で作成した同じスクリプトを TruClient と比較してみます。どちらのシナリオでも、思考時間/待機時間、仮想ユーザー数、ペーシングは同じです。
各トランザクションの時間がほぼ同じである可能性はありますが、通過したトランザクションの総数に関しては非常に異なりますか?
事前にタイ
Web HTTP/HTM1 プロトコルでは、応答時間= 処理時間 + 待ち時間 (データ転送中にネットワークでかかる時間)。
Truclient プロトコルでは、応答時間= 処理時間 + 待ち時間 + レンダリング時間
したがって、両方の応答時間の違いがわかります。
また、実行時間は両方のプロトコルで異なるため、渡されたトランザクションの総数も異なります。
問題は、何を測定しようとしているのかということです。サーバーの応答時間を測定しようとしていますか、それとも応答時間の影響におけるクライアントの重みを測定しようとしていますか? 私は、開発ツールと機能テストの両方で開発者ツールを使用して取得した時間を調べることで、クライアントの重みを測定できるという仮説を立てました。
このクライアントの重みの多くはページ アーキテクチャに関連しているため、ページ アーキテクチャに問題があることがパフォーマンス テストで示されるのを待っていると、本番環境に移行する前に問題を修正して再テストする時間がない可能性があります。
また、Steve Souders の収集した O'Reilly の作品をお勧めします。これは、ページ デザインのクライアント バウンドの概念と、これがサーバーの応答速度以上にエンド ユーザー エクスペリエンスに与える影響を理解するのに役立ちます。