什麼是 dynaTrace Ajax

時間 2019-11-10

標籤什麼 dynatrace ajax 欄目 Ajax 简体版

原文原文鏈接

隨着 jQuery、Dojo、YUI 等框架的興起讓構建 Web2.0 應用更加容易，但隨之帶來的定位等應用問題也愈來愈難，尤爲是與性能相關的。dynaTrace Ajax Edition 是一個強大的底層追蹤、前端性能分析工具，該工具不只可以記錄瀏覽器的請求在網絡中的傳輸時間、前端頁面的渲染時間、DOM 方法執行時間以及 JavaScript 代碼的解析和執行時間，還能夠跟蹤 JavaScript 從執行開始，通過本地的 XMLHttpRequest、發送網絡請求、再到請求返回的全過程。html

dynaTrace Ajax 目前有兩個版本，免費版和商業版，它們之間的區別可查看版本比較，本文主要是針對免費版本的介紹。在 3.0 以前的版本只支持運行在 IE 瀏覽器下，包括 IE六、IE七、IE8，在 3.0 Beta 版以後可同時支持在 IE 和 Firefox 瀏覽器上的性能跟蹤。前端

回頁首html5

dynaTrace Ajax 安裝和使用

下載 DynaTrace 最新的版本 , 雙擊安裝文件，點擊「下一步」即可完成安裝，安裝好的操做界面如圖 1 所示：web

圖 1. 安裝好的操做界面

點擊中間齒輪狀的圖標可對工具的屬性進行配置，以下圖 2 所示：ajax

圖 2.Preferences( 屬性配置 )

從上圖的：編程

「General 」面板：可設置服務端口，網絡代理設置以及瀏覽器的啓動路徑等；
「Agent 」面板：可設置獲取參數的配置，例如可配置是否獲取 DOM 的訪問或方法參數和返回值等，默認會選擇全部選項。

能夠經過兩種方式啓動 DTA 跟蹤您的頁面：瀏覽器

直接經過工具啓動，如圖 1 所示，點擊瀏覽器旁邊的下拉按鈕進入 「Manage Run Configurations」 或直接點擊 「New Run Configuration」添加所要跟蹤的 URL。因爲它能夠運行在多頁面的工做流之下，能夠先輸入起始網址，而後導航到其餘網頁，dynaTrace 會在後臺監視一切。
圖 3.Manage Run Configurations( 管理運行配置 )
從瀏覽器啓動 dynaTrace: 先打開瀏覽器，進入須要跟蹤的界面，再點擊瀏覽器工具欄的按鈕，以下圖所示（使用前在瀏覽器插件中 Enable 該工具 ),Connected/not Connected 用以表示當前的追蹤狀態
圖 4. 瀏覽器啓動

在關閉瀏覽器以前，能夠快速看一下 dynaTrace 軟件界面，會看到在「Browsers 」下面有一個節點，那就是當前正在從瀏覽器中收集的信息。咱們能夠在運行瀏覽器的同時分析這些數據，也能夠關閉瀏覽器，再從 Sessions 中分析捕獲的信息。緩存

此外，在實際的操做過程中，可能會須要跟蹤打開頁面後的一系列操做（例如點擊某個按鈕觸發的事件等）, 免費版的 dynaTrace 跟蹤的信息不能按照 Page 或者 Action 自動進行分離，這種狀況下，咱們能夠經過在操做過程當中經過添加標記 (Insert Mark ) 的方式從 PurePath 視圖中來區分每一個 Action 行爲的時間分割。即在操做前添加一個標記，操做完成後再添加一個標記，再從 PurePath 視圖中分析所添加標記之間的比較耗時的請求。以下圖 5 所示：服務器

圖 5. 添加標記 (PurePath 視圖 )

此外，它還具備導入導出的的功能即將收集到的數據導出爲 session 文件再導入到 DynaTrace 裏面進行分析。具體操做可經過在 Cockpit 面板中 Sessions 文件夾下選擇要導出的 Session，右鍵或者從工具條裏的點擊 Export Session 按鈕即能完成導出操做，導入文件的操做與此相似。網絡

回頁首

背景知識

在討論 dynaTrace 工具以前，先簡單瞭解一下在 Web2.0 下常常會碰到的一些客戶端的性能問題，這些話題雖然不是本文的主題，可是和本文密切相關，由於您知道了大體存在的問題，再使用相應的工具去發現這些問題就會簡單不少。

在 Web2.0 應用程序中，JavaScript 的執行經常會阻礙瀏覽器端資源的下載和增長頁面的 Loading 的時間，致使這個問題的因素主要有：

瀏覽器自己的因素，例如在 IE 瀏覽器下 ,CSS Selectors 的查找速度相比其餘瀏覽器如 Firefox 相對會慢不少
CSS 對相同對象的查詢次數太多
存在太多 Ajax 的 XMLHttpRequest 請求
JS、CSS、圖片數量過多，增長了網絡傳輸開銷
DOM 的尺寸太大，一方面會增長內存的佔用，另外一方也會影響頁面的性能，例如 CSS 的查詢操做
豐富的 DOM 操做，例如建立新的 DOM 元素或是做爲 HTML 形式添加新的元素等
過多的事件處理綁定（Event Handler Bindings）等

下面將結合實際工做中碰到的案例，介紹如何使用 dynaTrace 來跟蹤和分析客戶端的性能問題。

回頁首

應用案例分析

下面記錄的結果是以咱們目前正開發的一個實際項目（IBM Docs）中的一個案例 - 在 Web 中打開一個 PPT 文檔，根據 dynaTrace 收集的信息來分析存在的性能問題。

Performance Report( 性能報告視圖 )

從 Cockpit 面板中打開 Performance Report 視圖，如圖 6 所示：

圖 6. 性能報告

性能報告視圖中記錄了全部訪問的網頁的詳細信息，從這個視圖當中咱們能夠獲得如下信息：

載入頁面所消耗的時間 ：OnLoad Time[ms] 顯示從頁面開始載入到瀏覽器派發 onload 事件所經歷的時間；Total Load Time[ms] 顯示頁面所有 load 完總共消耗的時間
JavaScript 執行時間 ：On Client[ms] 經過 JS API 或庫執行的全部 JavaScript 函數所消耗的總時間
網絡請求花了多長時間： 從 Remark 中可看到總共有多少請求數，其中有多少 XHR 請求等信息
服務器端所消耗時間： On Server[ms] 指客戶端發出的全部請求在服務器過了多長時間開始響應所消耗的總時間
從右下方的各個面板中能夠獲得整體的性能分析報告（更詳細的信息可查看 Cockpit 面板中的相應節點），例如：
- NetWork 中可看出有多少資源是從瀏覽器緩存中讀取的，有多少的 HTTP 轉發請求消耗了沒必要要的網絡傳輸時間；合併同一個 domain 中的 CSS、JS 的請求可節省多長網絡傳輸時間。
- TimeLine 中顯示了頁面的生命週期：該圖反映了頁面進程中網絡資源下載，JavaScript 執行，頁面發生渲染，CPU 使用狀況，以及發生了哪些事件，例如：Load 事件、XMLHttpRequest 等信息。

在個人例子中，如下內容引發了個人注意：

網絡耗時較長，請求數目太多：總共有 896 網絡請求，其中有 300+ 個 request 是對圖片的請求，300+ 個是從 cache 中對相同圖片的讀取。
JavaScript 執行時間總耗時 22 秒：從右下方的 JavaScript/Ajax(A) 報告中可看出有一個 OnLoad 的事件就消耗了總共 13 秒的時間，雙擊可從右邊窗口看出它的先後調用棧信息。
Server 端處理總共花了 20 秒的時間 : 這說明 Server 端也可能存在性能問題，可推薦你們使用 Performance Inspector工具去分析 Server 端的性能問題，這裏再也不詳述。
Remark 欄還顯示了頁面總共發出了 23 個 XMLHttpRequest 請求: 這能夠從時間軸的 event 行中找出發生的時間點。下一節將會針對這些問題進行更詳細的討論。

Timeline( 時間軸視圖） - 頁面生命週期

時間軸視圖能夠經過雙擊 Cockpit 面板中的 TimeLine 節點打開或者在 Performance Report 中經過在某個 URL 上點擊右鍵，選擇「DrillDown-TimeLine 」打開。根據 性能報告視圖 打開耗時比較長的 URL 的 TimeLine, 經過工具欄或右鍵菜單，能夠打開更多選項，好比內容類型和 JavaScript 觸發器的顏色值，或者顯示更多事件，好比鼠標移動、點擊和鍵盤事件。打開本案例的時間軸視圖，如圖 7 所示：

圖 7. 時間軸

在此視圖下，咱們可觀測到：

CPU 佔用率可顯示 JavaScript 的執行致使瀏覽器佔用 CPU 的時間
JavaScript 執行所佔用的時間：從上圖中觀察到右邊藍色塊的那一段耗時比較長，鼠標懸停在這段上能夠看到是因爲 load event on 觸發的，耗時將近 13 秒 的時間
瀏覽器 Rendering，懸停上去可發現大部分是因爲在計算 layout 所須要的時間，通常在 IE 上面執行相對會比較明顯
網絡請求並行下載耗時，一方面來自請求的數目太多，其中一個比較明顯的就是有一個 XMLHttpRequest 花在 Server 的處理耗時將近 7 秒的時間
Event 軸顯示了鼠標點擊事件，XMLHttpRequest 事件和 OnLoad 事件

放大右邊網絡請求時間比較長的部分（在個人例子中，從 16s 到 29s 時間片 ), 經過在開始處點擊鼠標左鍵拖拽到結束位置鬆開鼠標拖拽，視圖將放大到下面截圖中顯示的時間片上，以下圖 8 所示 :

圖 8. 放大時間軸

經過放大的時間片右鍵選擇「Drill Down to Timeframe e」進入 PurePath 視圖，顯示當前所放大的時間片上全部的活動。

PurePath( 路徑視圖 ) - JavaScript、DOM 和 Ajax 問題的詳細說明

能夠經過雙擊 Cockpit 面板中的 PurePath 節點打開也能夠選中時間軸上的一段右鍵選擇「Drill Down to Timeframe 」來到 PurePath 視圖，進一步進入每一個動做去觀察哪些事件觸發執行了 JavaScript 和哪些函數的執行耗時比較長。

這裏接着上節所述進入 PurePath 視圖 , 以下圖所示：

圖 9.PurePath 視圖

鼠標點擊上圖中的第二個時間片即 JS 佔用 14 秒的，面板同時會更新當前所選活的信息，顯示 JavaScript 代碼執行過程，包括每一個方法的執行時間和調用的參數及返回值。咱們不只能夠看到 JavaScript 方法，也能看到 DOM 訪問和 Ajax 請求。

從詳細信息欄咱們可觀察到

Start : 一個活動的開始時間
Duration[ms] : 活動的持續時間，包含子樹的活動時間
JS[ms] :JavaScript 執行總的耗時，包括異步的子樹執行時間但不包括等待時間
Total[ms] ：活動自己從開始到結束的持續時間 , 不包含子活動的執行時間
Exec[ms] ：活動自己執行時間，不包括其子活動的須要的時間
Size : 樹中總的節點數，包含全部子活動的節點數。

鼠標點擊上面任何一列可進行排序操做，根據 JS 執行時間長短經過鼠標點擊展開也能夠經過右鍵點擊「擴展子樹」展開層次圖找到是哪一個方法的調用致使執行了這麼長的時間。從上圖調用棧中可看出 contentDomHandle 來自應用程序的 JavaScript API 的調用總耗時最長，從它的子樹中可觀察到 JavaScript 執行的時間分佈：

addContextMenu<div> 方法執行次數比較多，雖然方法自己的執行時間 150ms，但調用次數比較多的話就會致使總的執行時間比較長。
SimulateSlideClick耗時2.5 秒
concord.util.events.publish耗時3 秒

爲了更方便發現這些函數的性能問題，能夠右鍵 contentDomHandle 方法，選擇「Drill Down->Hot Spots 」進入 HotSpots 視圖 。

另外，PurePath 視圖提供了多種分析方法，您能夠經過直接鍵入您要查找的內容來篩選或查找您須要的數據項，也經過右鍵菜單或工具欄按鈕添加過濾規則可讓軟件只顯示特定信息。

HotSpot( 熱點視圖 ) - 哪些地方下降了性能

綜上所述，能夠從 PurePath-->Drill Down 進入該視圖，也能夠從面板中直接打開 HotSpot 視圖來分析瀏覽中訪問過的全部 JavaScript、DOM 和頁面渲染操做。

接着上一節的 contentDomHandle () 方法調用爲例，以下圖所示：

圖 10.Hotspot 案例視圖

從上圖中能夠看到每一個方法的調用次數，JS 的執行時間以及總的執行時間等信息：

Back Traces 欄顯示了由誰調用了這個函數，調用了幾回，從上圖可看到該方法被 Dojo 的 <return-closure> 調用了 2 次，而方法自己調用的執行時間很短只有 3ms(Exec[ms])
Forward Traces 欄顯示了這個方法又調用了哪些函數，Invocations 表示該方法總共被調用了幾回；活動總耗時 12.7s(Total[ms]),Exec[ms] 表示方法自己執行所須要的時間，JS[ms] 總的 JavaScript 的執行時間。
界面底部顯示了在 Back Traces 樹或 Forward Traces 樹中選中的 JavaScript 的源碼

從個人例子中，就會很明顯的發現以下性能問題：

addContexMenu(<div>) 被調用了 30 次，JavaScript 執行消耗了將近 7 秒。根據瞭解這個方法的做用就是爲每一個 Slide 添加右鍵菜單，也就是說文件包含 30 頁就會被調用 30 次，這樣不只會增長瀏覽器的執行時間，也會佔用比較多的內存。
對於其餘兩個比較耗時的方法，simulateSlideClick 和 events.publish 方法各調用了將近 3 秒和 2.5 秒的時間，調用次數也很少，這就須要擴展 Trace 去看是否存在性能問題或還有能夠改進的地方；

到這裏咱們基本能夠找出從時間軸視圖中耗時 13 秒的 JavaScript 具體是被哪些函數的調用佔用了，也發現了一些比較明顯的性能問題。再回到 HotSpot 總的頁面看是否還有其餘性能問題 ( 從 Cockpit 面板中雙擊 HotSpot 節點 )，以下圖所示：

圖 11.HotSpot 視圖

上圖默認是按照操做或方法自己的耗時 (Exec[ms]) 不包括子方法來排序的 , 咱們發現除了瀏覽器的渲染比較耗時以外，最有可能存在性能問題的就是應用程序方法的調用。例如在我這個案例中，就發現如下幾個問題：

loadState 總共（包括子方法）執行了 3.7 秒，方法自己就消耗了將近 2 秒的時間，這個方法僅被調用了一次，是否有改進的空間就須要經過源碼看進去或直接跟開發人員溝通；
dojo.destroy(<div>) 被調用了 122 次，總共花了 1.3 秒的時間；

雙擊 dojo.destroy(div)，打開它的 Back Traces，以下圖所示：

圖 12.dojo.destroy

從上圖可得知，dojo.destroy(<div>) 僅被 applySlideSorterStyles 方法調用了一次就執行了 1 秒的時間，這也是比較可疑的性能問題。另外，您也能夠經過總的執行時間來排序，以下圖所示，這裏您能夠找到最耗時的方法的入口：

圖 13. 按總消耗時間排序

Network（網絡視圖） - 分析「對話」

最後咱們再來看一下 dynaTrace 的另外一個視圖 - Network 視圖，經過雙擊左側 Cockpit 面板中的 Network 節點，或從 Summary 視圖中某個 URL 上右鍵選擇「Drill Down – Network」進入到 Network 視圖，該圖顯示了全部網絡請求，以下圖所示：

圖 14.NetWork 視圖

Network 視圖高亮標記出超慢的請求以及鏈接等待時間。

這個視圖下會用顏色標記每一個請求，而且用紅色高亮標記出耗時最長的下載請求。默認狀況下會以 TimeLine 上的發生順序來排列，您能夠點擊任何一列來進行排序。對於每一個請求咱們能夠看到資源是否來自瀏覽器緩存（Cached 欄），請求類型（Network 或 Ajax），HTTP 狀態，Mime 類型，大小，在 DNS、網絡鏈接、服務器響應、網絡傳輸和等待上消耗的時間。界面底部顯示了 HTTP 請求和響應頭以及返回的實際內容。

常見的性能問題及解決辦法：

JS 或 CSS 的個數太多：需適當的合併同域下的 JS 或 CSS 以下降客戶端的請求數目
JS 的尺寸太大致使在局域網的條件下下載時間太長：能夠對尺寸比較大的文件在服務器端進行壓縮，例如使用 Dojo ShrinkSafe 或 YUI 進行壓縮
圖片數量太多：可以使用 CSS Sprites 將一些小的圖片組合在一塊兒成爲一張圖片，這樣能夠減輕服務器的負載，提升網頁的加載速度

回頁首

自動化收集數據

一般咱們都是對性能上有問題的頁面利用手動的方式訪問每一個頁面再用 dynaTrace 記錄和收集數據，但如果對每一個頁面都要記錄或是針對每一個不一樣的應用程序的版本僅對幾個頁面作這些操做也是須要付出比較大的人力。幸虧 dynaTrace 還提供了咱們一些新的 Feature 能夠用腳本工具代替人工方式驅動瀏覽器自動收集數據。當您用像 Selenium、Watir、WebAii 這樣的工具運行測試腳本時，dynaTrace 能夠自動從每一個瀏覽器 session 中收集性能信息。

如何使用 Selenium 整合 dynaTrace 實現自動化收集數據有兩種方式 ;

使用 DynaTrace 提供的一些高級的 Features, 如 dynaTrace Selenium Runner（僅商業版用戶） (com.dynatrace.webautomation.DynaTraceSeleniumRunner). 或 DynaTraceSeleniumHelper (com.dynatrace.webautomation.DynaTraceSeleniumHelper) 或使用 DynaTraceSelenium 替代 DefaultSelenium，如如下 code:

 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 是前端的軟件開發工程師和性能分析師的很是有用且重要的工具。經過該工具的不斷更新，功能的不斷強大，所支持的瀏覽器的不斷增長以及與持續集成工具相結合，這樣就能夠更容易、更早、更頻繁地發現應用程序在不一樣瀏覽器上的性能問題。

參考資料

學習

《dynaTrace Ajax 版使用指南》：參考如何使用 DynaTrace Ajax。
《在 Web2.0 中的十大客戶端性能問題》：分析在 WEB2.0 中致使客戶端的十大性能問題和案例分析。
《 How to include dynaTrace in your Selenium Tests 》：教您如何在 Selenium 測試中加入 dynaTrace，自動化收集數據。
《 Automation with dynaTrace Ajax Edition 》 :自動化參數環境變量配置詳解。
dynaTrace 主頁：查看 DynaTrace 的各種文檔。
《 Automation with dynaTrace Ajax Edition 》 :自動化參數環境變量配置詳解。
developerWorks Web development 專區：經過專門關於 Web 技術的文章和教程，擴展您在網站開發方面的技能。
developerWorks Ajax 資源中心：這是有關 Ajax 編程模型信息的一站式中心，包括不少文檔、教程、論壇、blog、wiki 和新聞。任何 Ajax 的新信息都能在這裏找到。
developerWorks Web 2.0 資源中心，這是有關 Web 2.0 相關信息的一站式中心，包括大量 Web 2.0 技術文章、教程、下載和相關技術資源。您還能夠經過 Web 2.0 新手入門欄目，迅速瞭解 Web 2.0 的相關概念。
查看 HTML5 專題，瞭解更多和 HTML5 相關的知識和動向。