隨著 jQuery、Dojo、YUI 等框架的興起讓構建 Web2.0 應用更加容易，但隨之帶來的定位等應用問題也越來越難，尤其是與性能相關的。dynaTrace Ajax Edition 是一個強大的底層追蹤、前端性能分析工具，該工具不僅能夠記錄瀏覽器的請求在網絡中的傳輸時間、前端頁面的渲染時間、DOM 方法執行時間以及 JavaScript 代碼的解析和執行時間，還可以跟蹤 JavaScript 從執行開始，經過本地的 XMLHttpRequest、發送網絡請求、再到請求返回的全過程。
dynaTrace Ajax 目前有兩個版本，免費版和商業版，它們之間的區別可查看 版本比較，本文主要是針對免費版本的介紹。在 3.0 之前的版本只支持運行在 IE 瀏覽器下，包括 IE6、IE7、IE8， 在 3.0 Beta 版之后可同時支持在 IE 和 Firefox 瀏覽器上的性能跟蹤。
--------------------------------------------------------------------------------
Trace A和使用
下載 DynaTrace 最新的版本 , 雙擊安裝文件，點擊“下一步”便可完成安裝，安裝好的操作界面如圖 1 所示：
圖 1. 安裝好的操作界面
點擊中間齒輪狀的圖標可對工具的屬性進行配置，如下圖 2 所示：
圖 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 視圖
若使用的是免費版，通過配置環境變量來實現自動化。就是設置在瀏覽器啟動時自動連接 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 相關的知識和動向。
關于作者
謝菊，IBM 中國軟件開發中心（CDL）Lotus 部門的軟件性能分析工程師，具有多個產品的性能測試經驗，如IBM Portal Accelerator 和IBM Docs。目前正在從事IBM Docs 產品服務器端以及客戶端的性能測試。