パフォーマンス分析図は、LoadRunnerのを説明しました
トランザクション（ユーザー交流分析）
ユーザー交流分析角度に立って、ユーザのパフォーマンス分析のための基礎です。
図1に示すように、トランザクションの独立Sunmmary（トランザクションレビュー）
トランザクションを直接システムが適切に機能しているかどうかを決定することができ、テスト時間のユーザートランザクション内で成功と失敗を分析することによって、パフォーマンス分析の包括的分析の最初のステップです。
図2は、平均Transaciton応答時間（トランザクション平均応答時間）
「トランザクション平均応答時間は、」平均時間試験シナリオの実行中にアプリケーションシステムに性能を分析することができ、それを通して、使用される試験シナリオ実行トランザクションの実行中に各第二を示します。
例：試験時間の変化により、システムのトランザクション処理速度は、試運転時とシステム変更の適用を示しており、減速し始め、全体的なパフォーマンスが低下傾向となります。
第二あたり3、トランザクション（秒/ TPSあたりのトランザクションの数によって）
「秒当たりのトランザクションの数によって/ TPS」シーンの秒は、各操作で各トランザクションを表示し、失敗回数が停止され、システム性能試験よう重要なパラメータ。これは、任意の時点でシステム時刻のトランザクション負荷によって決定することができます。TPS分析は、主に性能曲線の傾向を確認してください。
それはあなたが実行時間への影響を分析することができますトランザクションの数を比較することにより、平均トランザクション応答時間になります。
例：圧力が上昇した場合、CTR / TPS曲線が緩やかに変化またはフラットな傾向がある場合、サーバーのボトルネックを開始する可能性があります。
4、（毎秒トランザクションの総数）第当たりの総取引
シーンの「第2あたりのトランザクションの総数は」実行されて、それぞれが第渡されたトランザクションの合計数は、総務部と取引の合計数を止めることができませんでした。
5、トランザクションパフォーマンスSunmmary（トランザクション・パフォーマンスの概要）
「トランザクション・パフォーマンスの概要」のすべての取引の最小表示方式、最大および平均実行時間、応答時間は直接ユーザの要求かどうかを判断することができます。
それが原因の分析の必要性は、ユーザーの時間ではない許容範囲内であれば、業務の平均および最大実行時間をフォーカス。
負荷（トランザクション応答時間と負荷）下で6、トランザクション応答時間
「トランザクション応答時間と負荷」図、任意の時点で見ることができ、それを通して、「平均応答トランザクション時間」チャート、「仮想ユーザを実行する」組み合わせユーザー数とトランザクション応答時間の関係、ユーザは、ユーザのシステムの拡張のための参照を提供するために、システム内のデータの同時実行のパフォーマンスを知ることになります。この図は、段階的な負荷テストシナリオの分析のために、より便利な実行時間上の仮想ユーザーの負荷全体的な影響を、見ることができます。
7は、トランザクション応答時間（パーセンタイル） （ トランザクション応答時間（割合））
包括的な分析マップ「トランザクション応答時間（割合）は、」チャートによる間接的な取得のいくつかの統計解析ツールである得られた試験結果に基づいて分析されます。それは、与えられたトランザクション内で実行することができるトランザクション応答時間の割合によって分析することができます。
8、トランザクション応答時間（ディストリビューション） （ トランザクション応答時間（分布））
異なる応答時間をテストするトランザクションを理解することができ、「トランザクション応答時間（配信）は」動作中のシーンに表示され、配布を過ごしたトランザクションの実行時間、番号。事前に定義されたトランザクション関連の最小値およびトランザクションの最大許容応答時間の場合は、許容範囲内のサーバーのパフォーマンスかどうかを決定するために、このグラフを使用することができます。
Webリソース（ウェブリソース分析）
Webリソース分析、Webサーバーのパフォーマンス分析にサーバーから起動することです。
1は、毎秒ヒット数（秒当たりのクリック数）
でも、WebサーバーのHTTPリクエストに提出第二の仮想ユーザーの間、シナリオを実行している、「毎秒ヒット」。
これは、仮想負荷ユーザー生成の量によって評価することができ、そのよう「平均トランザクション応答時間」の比較表は、トランザクションのパフォーマンスに発生したクリック数の影響を見ることができます。ビューの安定性によって、あなたがシステムを決定することができます「毎秒クリック」。システムは通常、サーバの応答速度が遅いが低いCTRは、さらなる分析が必要で示し、我々は、システムのボトルネックことがわかりました。
図2に示すように、スループット（スループット）
「スループット」は、サーバの動作中に第2のスループット・シナリオごとに表示されます。毎秒仮想データ量によって表されるバイト内のどの測定値が所定のサーバから取得されます。
サーバー負荷の仮想ユーザー生成、およびトラフィックとボトルネックの存在という点で参照するには、サーバーの処理能力のスループットに基づいて評価することができます。
差分マップ「スループット」チャートと「ヒット」：
「スループット」チャートは、処理されたアプリケーションごとのHTTPサーバの数です。
「CTR」チャートは、サーバーからクライアントを取得するために、毎秒のデータの総量です。
図3に示すように、HTTPステータスコード概要（HTTPステータスコードの概要）
「の概要HTTPステータスコード」が示すHTTPステータスコードシナリオまたはセッション・ステップ・プロセスの数は、パケットの符号は、図によれば、Webサーバから返されます。HTTPステータスコードは、HTTPリクエストの状態を表しています。
1秒間に4、HTTP応答（毎秒のHTTP応答）
「第当たりHTTP応答」Webサーバーによって戻さ異なるHTTPステータスコードだけでなく、第2の戻りステータス情報コードの他の種類の数からシーンを実行する処理でありますサーバは、圧力下での操作を判定することができるエラーコードが生成されたスクリプトが位置するようにステータスコードを解析することによって、また、図面に示された結果によってグループ化することができます。
5、第二あたりのページ数のダウンローダ（秒あたりのダウンロードページ数）
「毎秒ダウンロードされたページの数は、」1秒当たりのページ数は、サーバのシナリオまたはセッションのステップの実行からダウンロードされることを示します。このマップを使用すると、ページ数に基づいて計算することができるには、仮想ユーザの負荷が生成され、ダウンロード。
そして、アイコンの数として図のスループットは毎秒ページダウンロードされるデータの量は、任意の第二に、サーバ仮想ユーザから受け取りました。しかし、各リソースのスループットが極端にサイズと見なさ（例えば、各GIFファイルのサイズ、各ページのサイズ）。第二のダウンロードあたりのページ数はページ数を考慮してください。
注：第2のマップごとにダウンロードされたページを表示するには、しなければならない「秒あたりのページ数（のみHTMLモード）」がRTSを設定します。
第二あたり6、再試行（秒当たりの回数の再試行）
「毎秒回の再試行」ステップを実行している各第2のシナリオまたはセッション・サーバへの接続試行回数を示しています。
サーバー接続が再試行され、次のような状況では：
A、初期接続の不正
B、プロキシ認証が必要となる
Cを、サーバが初期接続閉じ
D、接続できないサーバーへの初期接続
Eを、最初のサーバーは、負荷ジェネレータのIPアドレスを解決することはできません
7、要約（リトライ要約）再試行
パケットが理由を再試行それによれば、表示周波数と動作またはセッションサーバの試行中にシーンを接続する工程「概要を再試行」。このプロセスは時間を指し2回目のリトライ図当たりの回数をリトライ図で、このステップを実行しているサーバーとシーンまたはセッションを使用して決定することができます。
図8に示すように、接続（コネクション）
「接続」は、各時点が開かステップ動作中のTCP / IP接続またはセッションのシーンの数を示します。
このマップでは、あなたが他の接続を追加する必要があるときに知ることができます。
例：接続の数が急速に大きくパフォーマンスを向上させることができ、接続を追加し、定常状態とトランザクション応答時間に達して増加した場合（トランザクション応答時間を短縮します）。
図9は、秒あたりの接続（毎秒接続）
「毎秒接続が」毎秒動作プログラム中に確立されたTCP / IP接続の数を示しています。
理想的には、多くの HTTP要求は、新しい接続を開くためにではなく、それぞれの要求よりも、同じ接続を使用する必要があります。秒あたりの接続を介した図は、サーバーの処理が、それは、サーバーのパフォーマンスが徐々に低下することを示していることがわかります。
10は、SSLSパーセカンド（秒あたりのSSL接続）
「のSSL秒当たりの接続数」と新しいシーン番号のSSL接続またはセッションの実行を表示するには、再利用し、各第二のオープンを繰り返します。セキュアサーバーへのときオープンTCP / IP接続、ブラウザがSSL接続を開きます。
Webページ・ブレークダウン（ページ要素の細分化）
「ページ要素の細分化は、」主にページのコンテンツは、サイト上でこれらのグラフィックの詳細な分析をダウンロードすることができ、それを通してトランザクションの応答時間に影響を与えるかどうかを評価するために使用されて遅いか、問題の接続を中断
要素。
1、Webページ・ブレークダウン（ページ分解総合計画）
「ページ分解は、」テストプロセスにおける特定のトランザクションの応答を示し、その後、正常に実行に関連する事項を分析します。
「ページ分解」は、さらに4つの方法以下の図に従って細分することができる：
1）、ダウンロード時間Breaddown（ダウンロード時分割）が
異なる要素の図表示ページのダウンロード時間を「時間セグメントをダウンロード」するだけでなく、ダウンロードプロセスに従うことができますDNS解決の時間を表示するための異なる色の分解時間、接続を確立する時、初めて各バッファの割合。
2）、コンポーネント内訳（オーバータイム ）（ 時間コンポーネント内訳（変化します））
「コンポーネントの内訳」の図は、時間をかけて、選択細分化マップWebページの構成要素を示しています。この図から、我々は簡単にテスト中にどの要素不安定なダウンロード時間を見ることができます。この図は、クライアントがコントロールより多くのページ、応答時間解析コントロールをダウンロードする必要があるために特に適している、不安定または時間がかかるこれらのコントロールを簡単に見つけることができます。
3）、（オーバータイムの内訳ダウンロード時間）（ ）（時間的に変化するダウンロード時間の内訳を）
グラフは、選択したWebページの要素は時間セグメントをダウンロードする（時間変化）の状況を示す「時間ブレークダウン（オーバータイム）をダウンロード」それは非常に明確にストレステストプロセスの各要素のダウンロードページが表示されます。
「時間の内訳をダウンロードし、」チャートは統計解析の結果に応じて、テストページの要素全体の時間を示し、シナリオは、応答時間の統計毎秒内のページ要素に表示されているどのようなプロセス「時間ブレークダウン（オーバータイム）をダウンロード」結果として、両方のページ要素のマクロ及びミクロ分析ダウンロード時間の観点からのものです。
4）、第1バッファブレークダウンまでの時間 （オーバータイム）（ 第1のバッファ内訳（時間変化））
「（）時間的に変化する第1のバッファ内訳」チャートは、Webサーバから受信成功のリターンを示しています最初のバッファ、サーバーごとにページごとに第二成分のシーンやセッションと（秒）ネットワークの時間を実行する工程の前に期間。これは、サーバやネットワークの動作中の時間ステップの図シーン又はセッションを決定するために使用することができます。
第一のバッファ時間：バッファが使用された最初の時間を受信するブラウザに、クライアントにデータネットワークを介してサーバからサーバとの接続、最初のパケット送信開始時間を確立するクライアントを指します。
図2は、ページ・コンポーネントの故障（ページコンポーネントブレークダウン）
「ページのコンポーネントの故障は、」チャートは、各ページ及び（秒）そのコンポーネントの平均ダウンロード時間を示しています。図の欄には、秒の平均数に応じて、当該部品の特定に役立ち、それを通してコンポーネントをダウンロードソートすることができます。
図3は、ページコンポーネントブレークダウン（オーバータイム ）（ ページ（）は時間的に変化する組立分解）
のグラフは、それぞれ、第2の実施形態の動作時平均応答ページあたりの時間とそのコンポーネントを示している「ページは（時間に対する）組立分解しました」 （秒単位）。
4、ページ（ページが時間ブレークダウンをダウンロード）時間の内訳をダウンロード
「ページダウンロード時間ブレークダウン」の図は、各ページのコンポーネントのダウンロード時間の内訳は、ダウンロード・トランザクションの応答時間の間、同社のウェブサイトに応じて決定することができることを示すことは遅い、またはネットワークエラーが原因サーバーによる誤差。
図DNS解決時間、接続時間、第一のバッファ、SSLハンドシェイク時間、受信時間、FTP検証時間、およびセグメントへのダウンロード処理のためのクライアント時間誤差時間各成分までの時間に応じて「ページのダウンロード時間セグメント」 。
図5に示すように、ページ（オーバータイムの内訳をダウンロード （時間） ページのダウンロード時間セグメント（時変））
「ページのダウンロード時間セグメント（時変）」シナリオ中の図表示、各ページ・コンポーネントの各第二ダウンロード時間細分化。図は、この問題を決定するプログラムの実行中のどの時点でネットワークまたはサーバーで発生します。
「内訳（オーバータイム）ページのコンポーネント」チャートと「ページが時間ブレークダウン（オーバータイム）をダウンロードは、」チャートは通常、分析のために組み合わされて：最初の質問でコンポーネントを決定し、次にその理由を見つけるように、彼らのダウンロードプロセスを分析しますどこ。
図6に示すように、タイム第1バッファ故障（第1バッファブレークダウン）に
正常に戻って、Webサーバから受信される最初のバッファ前にこの期間内の各ページ・コンポーネントの「第1のバッファ内訳、」チャート関連するサーバー/ネットワークタイム。ダウンロード時間のコンポーネントが非常に長い場合は、関連するサーバーおよびネットワークに関連または起因する問題を決定するために、このグラフを使用することができます。
ネットワークタイム：最初のように定義 HTTPリクエストその瞬間、確認されるまでの経過の平均時間。
サーバー時間：初期の領収書からのように定義 HTTPリクエストの確認が成功した最初のバッファの間で経過し、Webサーバーから平均時間を受信するまで始めます。
図7は、時間（第1のバッファブレークダウンまでの時間以上）（ 第1のバッファ内訳（時変））が
正常に最初のWebサーバから返された「第一のバッファブレークダウン（経時）」グラフ番組を受信しましたバッファ、毎回各動作シーンとネットワーク時間の2ページ目のサーバーコンポーネントの前にこの時間の間。あなたは、シナリオサーバやネットワークの間の時間に問題が点を決定するために、このチャートを使用することができます。
8、Downloaderの部品サイズ（KB） （ダウンロードコンポーネントサイズ）
ダウンロードされた各Webページの「ダウンロード部品サイズ」チャートはサイズに設定されています。それは、比較的大きく、さらに性能を向上させるために最適化される必要がアセンブリによって直接見ることができます。