dynaTrace Ajax：フロントエンドパフォーマンス分析ツール

Dynatrace Ajax Front End Performance Analysis Tool

dynaTraceAjaxとは

jQuery、Dojo、YUIなどのフレームワークの台頭により、Web 2.0アプリケーションの構築は容易になりましたが、特にパフォーマンスに関連して、ポジショニングなどのアプリケーションの問題はますます困難になっています。 dynaTraceAjaxエディション これは、ネットワーク上のブラウザー要求の転送時間、フロントエンドページのレンダリング時間、DOMメソッドの実行時間、および解析と実行を記録するだけでなく、強力な低レベルのトレースおよびフロントエンドパフォーマンス分析ツールです。 JavaScriptコードの時間。 JavaScriptは実行から始まり、ローカルのXMLHttpRequestを通過し、ネットワークリクエストを送信してから、リクエストに戻ります。

dynaTrace Ajaxは現在、無料と商用の2つのバージョンで利用可能であり、それらの違いを確認できます。 バージョン比較、 この記事は主に無料版の紹介を目的としています。 3.0より前のバージョンは、IE6、IE7、IE8などのIEブラウザーでの実行のみをサポートし、3.0ベータ以降のIEおよびFirefoxブラウザーでのパフォーマンス追跡のサポートをサポートします。

dynaTraceAjaxのインストールと使用

ダウンロード DynaTrace 最新バージョンでは、インストールファイルをダブルクリックし、[次へ]をクリックしてインストールを完了します。インストールされた操作インターフェイスを図1に示します。

下の図2に示すように、中央の歯車のアイコンをクリックして、ツールのプロパティを構成します。

上の写真から：

• 「」 一般 'パネル：ブラウザのサービスポート、ネットワークプロキシ設定、起動パスを設定できます
• 「」 エージェント パネル：DOMまたはメソッドのパラメーターと戻り値にアクセスできるかどうかなど、パラメーターを取得するための構成を設定できます。デフォルトでは、すべてのオプションが選択されています。

ページを追跡するためにDTAを開始する方法は2つあります。

1. 図1に示すように、ツールを直接使用して開始します。ブラウザの横にあるドロップダウンボタンをクリックして入力します。 「実行構成の管理」 または直接クリック 「新しい実行構成」 追跡するURLを追加します。複数ページのワークフローで実行できるため、開始URLを入力してから他のWebページに移動すると、dynaTraceがバックグラウンドですべてを監視します。
   
   図3.実行構成の管理
   
   
   
2. ブラウザからdynaTraceを起動します。最初にブラウザを開き、追跡する必要のあるインターフェイスを入力してから、以下に示すように、ブラウザツールバーのボタンをクリックします（使用する前にブラウザプラグインでツールを有効にします）。接続済みは、現在の追跡ステータスを示すために使用されます
   
   図4.ブラウザーの起動
   
   
   

   ブラウザを閉じる前に、dynaTraceソフトウェアインターフェイスをすばやく確認できます。 ブラウザ '下にノードがあります。これは、現在ブラウザから収集されている情報です。ブラウザの実行中にデータを分析するか、ブラウザを閉じてから セッション キャプチャした情報を分析します。

また、実際の操作では、ページを開いた後の一連の操作（ボタンをクリックしてイベントをトリガーするなど）を追跡する必要がある場合があり、無料版のdynaTrace追跡情報を自動的に分離することはできません。ページまたはアクションに、これは操作中にタグを追加することでこれを行うことができる場合（ マークを挿入 からの道 PurePath ビューは、各アクション動作の時分割を区別するために使用されます。つまり、操作の前にタグを追加し、操作の完了後にタグを追加してから、 PurePath ビューは、追加されたタグ間の時間のかかるリクエストを分析します。以下の図5に示すように：

また、インポートとエクスポートの機能もあります。収集されるデータはセッションファイルにエクスポートされ、分析のためにDynaTraceにインポートされます。特定の操作は コックピット パネル内 セッション フォルダの下にエクスポートするセッションを選択し、ツールバーから右クリックまたはクリックします エクスポートセッション ボタンはエクスポート操作を完了することができ、インポートファイルも同様です。

背景知識

dynaTraceツールについて説明する前に、Web2.0で頻繁に発生するクライアントパフォーマンスの問題のいくつかを簡単に見てみましょう。これらのトピックはこの記事の主題ではありませんが、一般的な問題を知っているため、この記事と密接に関連しています。これらの問題を見つけるためにツールを使用する方がはるかに簡単です。

Web 2.0アプリケーションでは、JavaScriptを実行すると、ブラウザー側のリソースのダウンロードが妨げられ、ページの読み込み時間が長くなることがよくあります。この問題の主な原因は次のとおりです。

• IEブラウザーなどのブラウザー自体、CSSセレクターはFirefoxなどの他のブラウザーよりも遅く見えます
• CSSに同じオブジェクトに対するクエリが多すぎます
• AjaxXMLHttpRequestリクエストが多すぎます
• JS、CSS、および画像の数が多すぎるため、ネットワーク送信のオーバーヘッドが増加します
• DOMのサイズが大きすぎるため、一方ではメモリ使用量が増加し、もう一方ではCSSクエリ操作などのページのパフォーマンスにも影響します。
• 新しいDOM要素の作成やHTMLとしての新しい要素の追加などの豊富なDOM操作
• 過剰なイベントハンドラーバインディング（イベントハンドラーバインディング）など。

次のセクションでは、dynaTraceを使用してクライアントのパフォーマンスの問題を追跡および分析する方法を紹介します。

アプリケーションケース分析

以下に記録されている結果は、現在開発中の実際のプロジェクト（IBM Docs）の場合です。WebでPPTドキュメントを開き、dynaTraceによって収集された情報に基づいてパフォーマンスの問題を分析します。

パフォーマンスレポート（パフォーマンスレポートビュー）

コックピットパネルから開く パフォーマンスレポート 図6に示すビュー：

パフォーマンスレポートビューには、アクセスしたすべてのWebページの詳細が記録されます。このビューから、次の情報を取得できます。

• ページの読み込みに費やした時間 ：OnLoad Time [ms]は、onloadイベントをディスパッチするためにページがブラウザにロードされてから経過した時間を示します。TotalLoadTime [ms]は、ページで費やされた合計時間を示します。
• JavaScriptの実行時間 ：On Client [ms] JSAPIまたはライブラリによって実行されるすべてのJavaScript関数によって費やされた合計時間
• ネットワークリクエストにはどのくらい時間がかかりましたか： Remarkから、リクエストの総数、XHRリクエストの数などを確認できます。
• サーバー側で費やされた時間： On Server [ms]は、サーバーが経過した後、クライアントからのすべての要求が応答を開始するのにかかる合計時間を指します。
• 全体的なパフォーマンス分析レポートは、右下のさまざまなパネルから入手できます（詳細については、コックピットパネルの対応するノードを参照してください）。次に例を示します。
  • 通信網 ブラウザのキャッシュから読み取られるリソースの数、不要なネットワーク送信時間を消費するHTTP転送リクエストの数、同じドメインでCSSリクエストとJSリクエストを組み合わせることでネットワーク送信時間を節約できる時間はどれくらいかがわかります。 。
  • タイムライン ページのライフサイクルが表示されます。グラフには、ネットワークリソースのダウンロード、JavaScriptの実行、ページのレンダリング、CPU使用率、およびLoadイベントやXMLHttpRequestなどのページプロセス中に発生したイベントが反映されます。

私の場合、次のコンテンツが私の注意を引きました。

1. ネットワークに時間がかかり、リクエスト数が多すぎます。合計896のネットワークリクエストがあり、そのうち300以上のリクエストが画像のリクエストであり、300以上がキャッシュ内の同じイメージからの読み取りです。
2. JavaScriptの実行時間は合計22秒かかります。右下のJavaScript / Ajax（A）レポートから、OnLoadイベントが合計13秒を消費していることがわかります。ダブルクリックすると、右側のウィンドウから前面と背面のコールスタックを確認できます。情報。
3. サーバー側の処理には合計20秒かかりました。これはサーバー側でパフォーマンスの問題がある可能性があることを示しているため、すべての人に使用することをお勧めします。 パフォーマンスインスペクター このツールはサーバー側のパフォーマンスの問題を分析するため、ここでは詳しく説明しません。
4. [備考]列には、ページが合計23個のXMLHttpRequestリクエストを発行したことも示されています。これにより、タイムラインのイベント行から特定の時点を見つけることができます。次のセクションでは、これらの問題について詳しく説明します。

タイムライン（タイムラインビュー）-ページのライフサイクル

タイムラインビューは、コックピットパネルでダブルクリックできます タイムライン ノードを開くか、パフォーマンスレポートのURLを右クリックして、[']を選択します。 ドリルダウン-タイムライン '開いた。による パフォーマンスレポートビュー 時間がかかるURLを開く タイムライン 、ツールバーまたは右クリックメニューから、コンテンツタイプの色の値やJavaScriptトリガーなどのオプションをさらに開いたり、マウスの動き、クリック、キーボードイベントなどのイベントを表示したりできます。図7に示すように、このケースのタイムラインビューを開きます。

このビューでは、次のことを確認できます。

1. CPU使用率は、JavaScriptの実行によってブラウザがCPU時間を消費するタイミングを示します
2. JavaScriptの実行にかかる時間：上の写真から右側の青いブロックを観察するのに長い時間がかかります。このセクションにカーソルを合わせると、次の理由でマウスが表示されます。 のロードイベント トリガーされ、時間がかかる 13秒 時間
3. ブラウザのレンダリング、ホバーアップ、そしてそのほとんどがレイアウトの計算に必要な時間によるものであることがわかりました。一般的にIEで言えば比較的明白です。
4. ネットワークリクエストの並列ダウンロードには時間がかかりますが、リクエストの数が多すぎることから、サーバーの処理にXMLHttpRequestが7秒近くかかることは明らかです。
5. イベント軸には、マウスクリックイベント、XMLHttpRequestイベント、およびOnLoadイベントが表示されます。

ネットワーク要求時間の右側にズームインします（私の場合は、 16秒 に 29秒 タイムスライス ）、 最初にマウスの左ボタンをクリックし、最後の位置にドラッグして、マウスドラッグを放します。以下の図8に示すように、ビューは下のスクリーンショットに示されているタイムスライスに拡大されます。

拡大したタイムスライスを右クリックして、「」を選択します。 時間枠にドリルダウン e」PurePathビューに入り、現在ズームインされているタイムスライスのすべてのアクティビティを表示します。

PurePath（パスビュー）-JavaScript、DOM、およびAjaxの問題の詳細な説明

コックピットパネルをダブルクリックして行うことができます PurePath ノードが開いている場合は、タイムラインを右クリックして 'を選択することもできます。 時間枠にドリルダウン 「PurePathビューに移動し、各アクションにさらに進んで、JavaScriptの実行をトリガーするイベントと、実行に時間がかかる関数を確認してください。」

以下に示すように、前のセクションで示したPurePathビューを次に示します。

上の画像の2番目のタイムスライスであるJSをクリックすると、14秒かかります。パネルは、現在選択されているライブ情報も更新し、JavaScriptコードの実行を示します。これには、各メソッドの実行時間、呼び出しのパラメーターと戻り値が含まれます。 JavaScriptメソッドを確認できるだけでなく、DOMアクセスとAjaxリクエストも確認できます。

詳細バーから観察できます

• 開始 ：イベントの開始時間
• 期間[ミリ秒] ：サブツリーのアクティビティ時間を含む、アクティビティの期間
• JS [ms] ：JavaScript実行の合計時間（非同期サブツリー実行時間を含むが待機時間は含まない）
• 合計[ms] ：アクティビティ自体の開始から終了までの期間。子アクティビティの実行時間は含まれません。
• Exec [ms] ：サブアクティビティに必要な時間を除く、アクティビティ自体の実行時間
• サイズ ：すべての子アクティビティのノード数を含む、ツリー内のノードの総数。

上記の列のいずれかをクリックすると、並べ替えることができます。 JSの実行時間によっては、[拡張サブツリー]をクリックして階層を展開し、どのメソッドの呼び出しがこれほど長い時間実行されたかを確認することもできます。上の図のコールスタックからわかるように contentDomHandle アプリケーションからJavaScriptAPIの呼び出しに最も時間がかかり、JavaScript実行の時間分布はそのサブツリーから確認できます。

• addContextMenuメソッドには多数の実行があります。メソッド自体の実行時間は150msですが、呼び出し回数が比較的多いため、合計実行時間が長くなります。
• SimulateSlideClicktime consuming 2.5秒
• concord.util.events.publishtime consuming 3秒

これらの機能のパフォーマンスの問題を見つけやすくするには、右クリックします contentDomHandle 方法、選択 ' ドリルダウン->ホットスポット 入る HotSpotsビュー 。

さらに、PurePathビューにはさまざまな分析方法が用意されており、探しているものを直接入力することで必要なデータアイテムをフィルタリングまたは検索できます。また、右クリックメニューまたはツールバーボタンからフィルタリングルールを追加すると、ソフトウェアで表示できます。特定の情報のみ。

HotSpot（ホットスポットビュー）-パフォーマンスはどこで低下しますか？

要約すると、PurePath-> Drill Downからこのビューにアクセスするか、パネルから直接HotSpotビューを開いて、ブラウズでアクセスしたすべてのJavaScript、DOM、およびページレンダリング操作を分析できます。

次に、前のセクション contentDomHandle 次の図に示すように、（）メソッド呼び出しは例です。

上の図から、メソッドごとの呼び出し数、JSの実行時間、および合計実行時間がわかります。

• バックトレース この列は、この関数を誰が数回呼び出したかを示しています。上の図から、メソッドがDojoによって2回呼び出され、メソッド自体の実行時間はわずか3ms（Exec [Ms]）であることがわかります。
• フォワードトレース この列には、このメソッドによって呼び出される関数が表示されます。呼び出しは、メソッドが合計で数回呼び出されたことを示し、アクティビティには合計12.7秒（Total [ms]）かかり、Exec [ms]は、メソッド自体の実行に必要な時間を示します。JS[Ms] JavaScriptの合計実行時間。
• バックトレースツリーまたはフォワードトレースツリーで選択されたJavaScriptのソースは、インターフェイスの下部に表示されます。

私の例から、次のパフォーマンスの問題が見つかっていることは明らかです。

1. addContexMenu（）が30回呼び出され、JavaScriptの実行に7秒近くかかりました。この方法の理解によると、スライドごとに右クリックメニューを追加します。つまり、ファイルに30ページが含まれていると、30回呼び出され、ブラウザの実行時間が長くなるだけでなく、より多くのメモリを消費します。
2. 他の2つの時間のかかるメソッドの場合、simulateSlideClickメソッドとevents.publishメソッドはそれぞれ約3秒と2.5秒を呼び出し、呼び出しの数はそれほど多くありません。これには、パフォーマンスの問題や改善があるかどうかを確認するためにトレースを拡張する必要があります。場所

この時点で、基本的に、タイムラインビューから13秒かかるJavaScriptは、関数が呼び出されるときに特に占有されていることがわかります。また、いくつかの明らかなパフォーマンスの問題も見つかります。 HotSpotの合計ページに戻って、他のパフォーマンスの問題があるかどうかを確認します（コックピットパネルからダブルクリックします） HotSpot ノード）、以下に示すように：

上の図は、デフォルトで操作に従ってソートするか、メソッド自体の消費時間（Exec [ms]）にサブメソッドが含まれていません。時間のかかるブラウザのレンダリングに加えて、最も可能性の高いパフォーマンスの問題はアプリケーションの方法であることがわかりました。コール。たとえば、私の場合、次の問題が見つかりました。

1. loadStateの合計（サブメソッドを含む）は3.7秒間実行され、メソッド自体はほぼ2秒を消費しました。このメソッドは一度だけ呼び出されました。改善の余地がある場合は、ソースコードを確認するか、開発者と直接連絡する必要があります。
2. Dojo.destroy（）は122回呼び出され、合計1.3秒かかりました

以下に示すように、dojo.destroy（div）をダブルクリックして、バックトレースを開きます。

上の図からわかるように、dojo.destroy（）はapplySlideSorterStylesメソッドによって1秒間に1回だけ実行されます。これは、疑わしいパフォーマンスの問題です。または、次の画像に示すように、合計実行時間で並べ替えることもできます。ここで、最も時間のかかるメソッドへのエントリを見つけることができます。

ネットワーク-「会話」を分析する

最後に、dynaTraceの別のビュー（ネットワークビュー）を見てみましょう。左側のコックピットパネルでネットワークノードをダブルクリックするか、概要ビューでURLを右クリックして、[ドリルダウン]-[ネットワーク]を選択します。ネットワークビューに入ります。以下に示すように、すべてのネットワーク要求：

ネットワークビューは、超低速の要求と接続待機時間を強調表示します。

各リクエストはこのビューの下で色分けされており、最も時間のかかるダウンロードリクエストは赤いハイライトでマークされています。デフォルトでは、タイムラインで発生する順序で配置されており、任意の列をクリックして並べ替えることができます。リクエストごとに、リソースがブラウザキャッシュ（キャッシュされた列）、リクエストタイプ（ネットワークまたはAjax）、HTTPステータス、Mimeタイプ、サイズ、DNSで消費されたもの、ネットワーク接続、サーバーレスポンス、ネットワーク転送、待機時間からのものかどうかを確認できます。 HTTP要求および応答ヘッダーと、返される実際のコンテンツは、インターフェースの下部に表示されます。

一般的なパフォーマンスの問題と解決策：

• JSまたはCSSが多すぎます：同じドメイン内のJSまたはCSSを適切にマージして、クライアントからのリクエストの数を減らします
• JSのサイズが大きすぎるため、LANの条件下ではダウンロード時間が長くなりすぎます。たとえば、圧縮にDojo ShrinkSafeまたはYUIを使用して、サーバー側で大きなサイズのファイルを圧縮できます。
• 画像が多すぎる：CSSスプライトを使用して、小さな画像を1つの画像にグループ化できます。これにより、サーバーの負荷が軽減され、Webページの読み込み速度が向上します。

自動化されたデータ収集

通常、手動で各ページにアクセスし、dynaTraceを使用してデータを記録および収集しますが、ページごとまたは異なるアプリケーションごとに記録する場合は、ページ上でこれらの操作を実行するのに多くの人手が必要です。幸い、dynaTraceはいくつかの新機能も提供します。ブラウザを手動で駆動する代わりにスクリプトツールを使用して、データを自動的に収集できます。 Selenium、Watir、WebAiiなどのツールを使用してテストスクリプトを実行すると、dynaTraceは各ブラウザーセッションからパフォーマンス情報を自動的に収集します。

Seleniumを使用してdynaTraceを統合し、2つの方法でデータの収集を自動化する方法

• dynaTrace Selenium Runner（商用バージョンのみ）（com.dynatrace.webautomation.DynaTraceSeleniumRunner）やDynaTraceSeleniumHelper（com.dynatrace.webautomation.DynaTraceSeleniumHelper）など、DynaTraceが提供する高度な機能の一部を使用するか、DefaultSeleの代わりにDynaTraceSeleniumを使用します。 ：

 public class GoSpaceDynaTraceSeleniumTest { Selenium selenium = null @Before public void startup() { selenium = new DynaTraceSelenium('localhost', 4444, '*iexplore', 'http://localhost:9090') selenium.start() 

}

• 無料版を使用している場合は、環境変数を構成して自動化します。ブラウザの起動時にdynaTraceに自動的に接続するように設定されているため、Seleniumのスクリプトがブラウザの実行を開始すると、自動的にdynaTraceに接続し、dynaTraceにデータを自動的に収集させます。 Markを自動的に追加するには、Seleniumのスクリプトに次のコードを挿入します。

 void addMark(String marker) { defaultSelenium.runScript('try Unknown macro: { _dt_addMark('' + marker + '') } catch(e) { }') } 

結論

dynaTrace Ajaxは、フロントエンドのソフトウェア開発エンジニアやパフォーマンスアナリストにとって非常に便利で重要なツールです。ツールの継続的な更新、ツールの機能、サポートされるブラウザーの数の増加、継続的インテグレーションツールとの統合により、さまざまなブラウザーでのアプリケーションのパフォーマンスをより簡単に、より早く、より頻繁に見つけることができます。問題。