dynaTrace Ajax版使用指南[譯]

【原文出處】：http://blog.dynatrace.com/2009/11/17/a-step-by-step-guide-to-dynatrace-ajax-edition-available-today-for-public-download/

譯者按：dynaTrace是迄今為止在IE平台上出現的最好的javascript性能分析工具，沒有之一。他是不折不扣的王者。不過本人英文水平很爛，對於長篇英文閱讀起來相當吃力，為了后來的英文不好的同學讀起來不那么不那么難受，我就花點時間翻譯出來吧，作為前端工程師，應該掌握這樣優秀的工具，閑言碎語不多說，下面文章說端詳。

dynaTrace Ajax版學習指南，現可公開下載

dynaTrace Ajax內測版發布已有兩周了。它給你的第一印象是什么。那段時間內我們收到的所有反饋意見（例如來自 Steve Souders的意見,以及來自所有其他聯系形式和在線論壇的意見）使這款工具從它的早期版本過渡到它的第一個“官方”發布版成為可能。

在這篇博客里，我將就 dynaTrace Labs為什么要構建Ajax版工具展開討論，它解決了什么問題，以及如何在一個關於Google Maps的例子中使用它。

為什么要開發dynaTrace Ajax版——為什么免費？

在dynaTrace網站，我們看到我們的客戶跟業界一樣，將以瀏覽器和運行時（Javascript、DOM）為基礎的Web應用作為其應用平台。那些新興的框架，像 jQuery、 GWT、 YUI、 Dojo等，讓構建web 2.0應用越顯輕松——但是，也越來越難以確認應用中的問題到底是功能性的，還是與性能相關的。

即便是在企業環境中，排名第一的仍然是IE瀏覽器。IE的診斷工具在涉及問題分析時，常會給開發和測試人員帶來痛苦。在Web2.0/Ajax應用中所面對的挑戰不僅是要了解網絡交互（有多少資源以及什么時候載入），而且要了解這些交互是如何影響性能的。該問題所涉及的領域已經延伸到JavaScript、 XmlHttpRequests、DOM操作、框架、布局和渲染。dynaTrace Ajax版的來臨即可解決這類問題，以幫助用戶了解是什么原因導致現代Ajax應用中出現性能和功能問題。

那么，為什么免費呢？免費是因為我們想幫助開發和測試人員通過使用這款工具來解決web 2.0帶來的各種挑戰。我們也希望推廣 dynaTrace APM解決方案理念，即結合Ajax版所帶來的 端到端的瀏覽器到服務器的以事務為中心的應用性能管理解決方案。在這里可以繼續閱讀完整的 關於軟件免費的原因說明。

動手分析Google Maps——從安裝到分析的學習指南

我已經導出了學習這篇博文所需要的dynaTrace Ajax的session文件，點擊 這里免費下載，然后用它跟着我對我收集的這些數據進行逐步分析。如果你已經安裝了dynaTrace Ajax版軟件，就解壓縮這個zip文件，點擊工具欄中的導入按鈕導入session文件（.dtas），然后跳過前三步。

第一步：下載並安裝dynaTrace Ajax版

最一開始就是——對了，下載並安裝。

打開瀏覽器，進入 dynaTrace Ajax版網站，點擊 Download按鈕下載最新版本。你必須先注冊一個賬戶，這個賬戶不僅可以讓你下載該工具，還能給你在社區網站開通權限，在那里你可以獲得資訊、咨詢問題，甚至為軟件期望的功能提供建議。

第二步：啟動並查看dynaTrace Ajax版

點擊開始->所有程序->dynaTrace->dynaTrace AJAX Edition啟動dynaTrace。客戶端將出現Cockpit面板 （譯者注：左側）及歡迎界面 （譯者注：右側）。在我們開始追蹤Google Maps之前，讓我們先來瀏覽一下一些數據收集選項：

開始分析之前運行配置和預置功能

dynaTrace使用被稱為運行配置的方式，使你可以直接瀏覽你要分析的網站而不用每次都要在你的瀏覽器里鍵入url。你可以通過左上角工具欄中的下拉菜單來管理你的運行配置（添加新的、修改或者刪除現有的配置）。選擇Manage Run Configuration來預置http://www.google.com網站，參看下面的截圖：

管理網址

如截圖所示，也可以讓dynaTrace在開始追蹤網站之前情空瀏覽器緩存。這一功能在你要測試你的網站在沒有緩存的情況下運行的怎么樣時非常有用。另外一件重要的事是通過點擊工具欄最右側的按鈕可以啟動Preference（預置）對話框。

在Preference對話框中啟用捕捉參數

你可以在這里指定多個不同的配置。值得注意的是那個開啟/關閉捕捉JavaScript和DOM方法調用的選項，以及開啟/關閉Javascript一般追蹤的選項。在下面的練習里，請勾選“Capture arguments”以及“Capture full JavaScript call trace”選項。

第三步：開始分析Google Maps

讓我們開始吧。你既可以通過選擇工具欄中的Google運行配置，或者點擊歡迎界面的“Start Tracing”，再或者直接按F4快捷鍵來啟動軟件。接下來，dynaTrace將啟動一個IE的新窗口。如果你選擇了清除瀏覽器緩存，dynaTrace將在打開http://www.google.com之前開始執行這個操作（這可能會占用幾秒鍾的時間）。你可以通過瀏覽器程序圖標是否改變來判斷dynaTrace此時是否正在追蹤頁面執行過程——你會在瀏覽器窗口的左上角看到一個小dynaTrace圖標，以及一個dynaTrace工具欄顯示“已連接”：

通過dynaTrace啟動瀏覽器

如果你沒有看到這種情況出現，請到論壇的General Usage Question （譯者注：常見使用問題）版塊查詢故障排除技巧，或者通過在線反饋或論壇聯系我們。接下來，請跟我完成這些步驟：

1. 在搜索框里一字一頓的鍵入“dynaTrace”——每次輸入，你都會看到彈出Google的搜索建議框

搜索“dynaTrace”

1. 完成輸入后，按回車鍵或者點擊Google Search按鈕；
2. 當出現搜索結果后，點擊頁面頂部的“Maps”鏈接，切換到Google Maps；
3. 你將看到很多關於dynaTrace地點的搜索結果。點擊在“95 Hayden Avenue,Lexington,MA”的“dynaTrace Software”，讓地圖顯示這個地址。

用Google Maps搜索dynaTrace

這是我的測試結果。在我們關閉瀏覽器之前，你可以快速看一下dynaTrace軟件界面，你會看到在“Bowsers”下面有一個節點，那就是當前正在從IE中收集的信息。我們可以在運行瀏覽器的同時分析這些數據，也可以關閉瀏覽器，然后再分析我們捕獲的。讓我們動手分析吧——關閉瀏覽器，切換回dynaTrace AJAX軟件界面。

第四步：Summary視圖（摘要視圖）——高級分析

瀏覽器中記錄的事件被自動存儲在一個session （譯者注：會話）中，我們可以在瀏覽器關閉的情況下分析這些被捕獲的瀏覽器活動記錄。在左側cockpit面板中，你可以雙擊session，或者展開這個session節點，雙擊Summary節點。這兩種操作都會啟動Summary視圖，它為我們呈現session記錄中所有活動的高級分析結果：

Summary視圖顯示每個訪問過的URL的高級分析結果

Summary視圖顯示了session記錄中所有訪問過的URL鏈接的信息。點擊頂部表格中某個具體的url下方就會更新圖表和時間線來顯示所選鏈接的數據。在這個視圖中我們可以得到以下信息：

• 載入頁面所耗時間：Page Load Time[ms]（頁面載入時間[毫秒]）欄顯示從頁面開始載入到瀏覽器派發onload事件所經歷的時間；
• 網絡請求花了多長時間：下方NetWork餅圖從DNS解析、網絡連接、服務器響應以及網絡傳輸方面詳細分解網絡請求過程，由於網絡內容在這段時間里是並行下載的，所以NetWork[ms]欄則顯示的是所有網絡請求時間的總和；
• 下載了多少以及什么類型的資源文件，對比有多少資源是從瀏覽器緩存讀取的（Resource條形圖）；
• 通過JavaScript觸發器（腳本載入、載入完畢、鼠標、鍵盤等事件）和JavaScript API或庫執行的所有JavaScript函數一共耗時多長時間；
• 渲染頁面所占時間。瀏覽器必須計算布局並渲染頁面顯示。瀏覽器重新計算布局和重繪的時間取決於你的HTML、樣式表以及動態DOM操作。Rendering[ms]欄顯示了頁面在渲染工作上實際消耗的時間。
• 屏幕下方的時間軸圖顯示精確的頁面生命周期：該圖反映了頁面進程中網絡資源下載、JavaScript執行、頁面發生渲染的時間，CPU占用情況，以及發生了哪些事件。例如：onLoad事件、鼠標或鍵盤交互、XmlHttpRequests等。

在我們的例子中，以下內容引起了我的注意：

1. maps.google.com頁面的頁面載入時間為6.5秒：這是頁面在派發onload事件之前瀏覽器初始化html和所有引用的對象所消耗的時間；
2. 這頁面的網絡時間耗時12秒。當我觀察該頁面的Network餅圖時，我發現50%多的時間消耗在傳輸內容（這也可能意味着我的網速慢）上，42%的時間花在服務器響應上（指過了多長時間服務器開始響應），以及8%的時間消耗在與服務器建立物理連接上。
3. 總耗時3.6秒的JavaScript也是重要角色。JavaScript trigger餅圖顯示時間的具體消耗情況：載入script耗時2.1秒，onload事件派發耗時1.3秒，剩下的由鼠標點擊事件處理占用。
4. 時間軸還顯示頁面發出了2個XmlHttpRequest請求。它由一個小圖標標注在event行中請求發生的時間點上。下一節將進行更詳細的討論。

第五步：Timeline視圖（時間軸視圖）——近距離觀察頁面生命周期事件

時間軸視圖可以通過雙擊Cockpit面板中的Timeline節點打開，或者在Summary視圖中通過在某個URL上點擊右鍵，選擇“Drill Down-TimeLine”打開。我們用這種方式打開maps.google.com頁面：

查看某個url的Timeline

點擊“drill down （譯者注：詳細）”菜單將打開所選頁面的Timeline視圖，通過工具欄和右鍵菜單，你可以打開更多選項，比如內容類型和JavaScript觸發器的顏色值，或者顯示更多事件，比如鼠標移動，點擊和鍵盤事件。下面的截圖顯示時間軸開啟更多選項的效果：

針對選定頁面的Timeline顯示網絡、JavaScript、渲染、CPU和事件

我們可以在此視圖下做如下觀測：

1. 網絡請求並行下載來自6個不同域的內容；
2. 到瀏覽器派發onload事件大約需要6.5秒（圖中由IE圖標標識）；
3. 從maps.gstatic.com下載main.js耗時2.41秒（鼠標懸停在這段上可以看到詳細信息）；
4. main.js下載完成后，可以看到腳本實際執行耗時1.1秒，並觸發兩個JavaScript文件的下載（1秒）和另外2個JavaScript的執行（2秒）；
5. CPU占用率顯示JavaScript執行占用的瀏覽器CPU時間；
6. Event軸顯示了鼠標點擊事件，XmlHttpRequest事件和onUnload事件。

我們縮大鼠標第一次點擊到產生XmlHttpRequest請求的時段。在我的例子中，這個時間片是從11秒到12秒。通過在開始處點擊鼠標左鍵拖拽到結束位置來執行放大操作。當你松開鼠標拖拽的，視圖將放大到下面截圖中顯示的時間片上：

放大時間軸以顯示事件詳細信息

時間軸上顯示了點擊事件，一個XmlHttpRequest事件，其后緊隨一個onError事件，再后一點還有一個XmlHttpRequest(XHR)事件。鼠標懸停在事件上將顯示實際派發事件的DOM元素。鼠標懸停在JavaScript上將顯示腳本執行事件處理的時間，懸停在network請求上將顯示下載了哪些資源。我們也能看到瀏覽器執行了哪些類型的渲染。我們發現第一次鼠標點擊事件處理函數觸發新內容的加載——包括一個來自maps.gstatic.com的JavaScript文件。執行這個JavaScript文件——一旦它被加載以后——觸發了一個XHR請求。我們還能看到一個onError時間處理函數被觸發並且運行了240毫秒。

第六步：PurePath視圖（路徑視圖）——JavaScript、DOM和Ajax問題的詳細說明

從Timeline視圖（和從其他視圖一樣）我們可以更進一步進入每個動作去觀察事件觸發執行了哪些JavaScript函數和哪些JavaScript函數發出了XHR請求。在時間軸上點右鍵選擇“Drill Down to Timeframe”(進入詳細時間片)將來到PurePath視圖，並顯示當前所放大的時間片上所有的活動——如下圖：

進入指定時間片的PurePath視圖

在界面上方，我們可以看到所選時間片中瀏覽器的所有活動，包括由script標簽或事件響應觸發的JavaScript的執行情況。也包括網絡請求和渲染次數。Stats （譯者注：統計）欄顯示該行執行的JavaScript觸發的是計時器還是Ajax請求。那些占總體響應時間較多的活動會被彩色高亮顯示。

在PurePath列表中選擇一個活動，PurePath或JavaScript追蹤樹將更新顯示當前所選活動的信息。PurePath樹顯示了JavaScript代碼執行過程，包括每個方法執行的時間和調用的參數以及返回值（我們在第二步中開啟了參數捕獲選項）。代碼跟蹤也追蹤計時器調用，並把這些調用當做樹的一部分。我們不僅能看到JavaScript方法，也能看到DOM訪問和AJAX請求。

我們后退一步，回到前一個Timeline視圖。我對Ajax請求比較感興趣。雙擊Event行中的 圖標打開一個新的PurePath視圖，軟件會在JavaScript跟蹤中找出實際執行這個XmlHttpRequest的位置：

進入PurePath視圖分析XmlHttpRequest細節

在界面上方我們能看到的執行這段代碼的JavaScript文件——請看Details欄。在樹中我們能看到發出這個XHR請求的整個JavaScript執行過程，包括方法調用次數和調用參數。duration欄顯示JavaScript執行共耗時1127毫秒。這個時間包含了XHR返回的時間和等待JavaScript計時器的時間。打開這個網絡請求的詳細信息 （譯者注：在PurePath樹中定位的Network Request上點右鍵，選擇“Details”），將顯示Http請求和響應頭、請求的精確時間，包括連接、等待、服務器響應和網絡傳輸時間，還有從服務器返回的實際內容 （譯者注：在Details面板底部有個切換標簽Details/Response Content可以查看）。

XmlHttpRequest請求詳細信息

這個請求有趣的地方是服務器花了372毫秒返回了一個空的json對象。從這我們可以繼續分析，看一下是什么實際完成這個Ajax響應的。回到PurePath樹，我們“drill down”到onreadystatechange事件處理函數 （譯者注：在NetWork Request下有三個“JavaScript Execution”，是onreadystatechange觸發的三次函數調用，展開第三個可以看到這里的readyState為4，開始調用響應函數，一個匿名函數anonymous即是onreadystatechange的事件處理函數）。下面的截圖顯示了這個處理函數，右下方顯示這個函數的代碼：

分析XHR請求的JavaScript處理函數

這里最有意思的是左下方Contributor欄顯示了當前所選子樹的所有JavaScript活動。最上面一行顯示使用了一個動態script標簽，標簽的內容被寫入一段腳本來讓瀏覽器動態加載了一個JavaScript文件。雙擊Contributor欄中的這條數據定位到PurePath樹中的位置 （譯者注：可能要拖動橫向滾動條、拉寬PurePath樹的顯示寬度才能看到，這個位置折疊的層級很深）：

動態創建一個Script標簽並插入到DOM中

在這里我觀察到：

1. 一個計時器用了大概740毫秒來觸發計時器處理函數——注意截圖中第三行的setTimeout方法調用；
2. 創建了一個動態Script標簽，並把它添加到head中，指示瀏覽器下載這個Script文件。（譯者注：通過觀察我覺得“<標簽名>”即指代一個[標簽名]類型的DOM對象，.setAttrbute、.appendChild即為調用該DOM對象的DOM方法。）

PurePath視圖提供了多種分析方法。你可以通過直接鍵入 （譯者注：幾乎在任何地方都可以執行鍵入查找操作，只要點擊一下要查找信息的控件，使其獲得焦點，然后按鍵即可）你要查找的內容來篩選或查找你需要的數據項。通過右鍵菜單或工具欄按鈕添加過濾規則可以讓軟件只顯示特定信息。

第七步：Network視圖（網絡視圖）——分析“對話”

Network視圖顯示了發生在瀏覽器或各自頁面中的所有網絡請求。通過雙擊左側Cockpit面板中的Network節點，或從Summary視圖中某個URL上右擊選擇“Drill Down – Network”進入到Network視圖。在我的例子中，我回到Summary視圖，然后“Drill Down”進入maps.google.com的Network視圖：

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

這個視圖下會用顏色標記每個請求，並且用紅色高亮標記出耗時最長的下載請求。默認情況下，這個視圖是按“Time Chart”欄排序的，Time Chart欄顯示瀏覽器發送的請求隊列。

從每個請求上我們可以到的資源是否來自瀏覽器緩存（Cached欄），請求類型（Network或Ajax），HTTP狀態，Mime類型，大小，在DNS、網絡連接、服務器響應、網絡傳輸和等待上消耗的時間。界面底部顯示了HTTP請求和響應頭以及返回的實際內容。這個頁面中有趣的地方是從mt0.google.com和mt1.google.com取回數據時的等待時間。每個瀏覽器針對每個域名都有一個連接數上限。

在我的例子中（WinXP系統，IE7瀏覽器）是每個域名最多保持兩個連接數。20個PNG圖片從兩個域中加載過來。由於連接數限制，使得每個域名只能並行下載兩個圖片。其他圖片便是不得不等待一個可用的連接數。這就解釋了為什么這些圖片和不斷增加的等待時間呈“瀑布”型。我們可能不希望在不同瀏覽器和不同連接數情況下出現像這里這樣的效果。解決這個問題是使用域名碎片（Domain Sharding）或者CSS拼圖（CSS Sprite）。

和其他視圖一樣，從這里可以進入PurePath。我們定位到頁面上第二個Ajax請求。對Kind列進行排序，然后選擇一個響應類型為text/xml的請求。點擊鼠標右鍵，選擇Drill Down->PurePath，進入PurePath視圖，軟件將自動定位到JavaScript追蹤中發出這個XHR請求的JavaScript函數上。

進入PurePath視圖

如果你的服務端運行有 dynaTrace APM，則可以進入 Server-side PurePath視圖，將顯示Java或.NET程序在服務端響應Ajax請求執行的細節。這里有 視頻可以了解更多。

第八步：Hotspot視圖（熱點視圖）——哪些地方降低了性能

最后一個有趣的視圖就是Hotspot視圖。通過Cockpit面板打開，或者Summary視圖打開來分析一個具體URL。本例中我們從Cockpit中打開HotSpot視圖來分析我訪問過的頁面中所有的JavaScript、DOM和渲染動作。

Hotspot視圖顯示了有問題的活動，包括活動前后的追蹤

上方的表格以聚合的方式顯示所有JavaScript、DOM和渲染動作。我們可以看到130次的Drawing動作，946次Reflow動作以及在一個div上調用了一個匿名函數1293次。這個列表是按總的執行時間排序的，性能越高排序越靠上。

雙擊這些中的一個，將顯示它執行前后的追蹤結果。Back Traces表顯示了誰來調用這些動作，Forward Traces表顯示的是這個動作又觸發了哪些動作。界面底部顯示了在Back Traces樹或Forward Traces樹中選中的JavaScript的源碼。我雙擊了那個調用946次的reflow動作。reflow動作在瀏覽器下載圖片或者其他對象或者應用樣式時觸發。不過，它也在訪問某些DOM屬性或調用某些DOM方法時觸發。在Back Traces中顯示讀取offset或height屬性會引起瀏覽器渲染引擎的一個reflow動作。回溯可以看到哪個JavaScript方法訪問了DOM。從界面上方的Contributor表可以進入PurePath視圖。打開PurePath將展開包含當前選中的方法的PurePath樹——類似前面我們展開XHR請求的PurePath樹。

第九步：自動化數據集

除了用dynaTrace手動收集數據，也可以用腳本工具代替人工方式驅動瀏覽器自動收集數據。當你用像 Selenium、 Watir、 WebAii這樣的工具運行測試腳本是，dynaTrace可以自動從每個瀏覽器session中收集性能信息。這里有篇博文《 5步實現性能自動分析》，教你如何用 Watir配合dynaTrace自動分析。

第十步：與你的同事分享數據

收集信息並制成離線版分析數據是dynaTrace的功能之一，上面你已經領略到了。如果你在別人的代碼中發現了問題，或者你想跟你的同事分享你的發現，你需要一種簡單的方式共享你收集到的數據。這可以通過把你的session導出為session文件實現。在Cockpit面板中的右鍵菜單或者工具條里的導出按鈕能完成這一工作。導入文件的操作與此類似。

導入導出dynaTrace session文件

總結和反饋

dynaTrace AJAX版是一款非常棒的針對IE6、7、8的分析和測試工具。社區已大力推廣第一個官方版軟件，它兼容前一個測試版。我們鼓勵大家積極參與這款軟件的推進工作，通過社區網站或軟件工具欄的報告功能報告使用問題。

工具欄中的反饋、分享和報告問題按鈕

工具欄里有三個按鈕可以讓你與好友分享這款軟件、給我們反饋信息或者報告使用問題。目前我們的許多客戶使用AJAX版來確定和解決他們的瀏覽器前端組件問題，至今我們已經從他們那里得到了一些很好的意見。這些用戶也使用了 集成dynaTrace無縫APM解決方案，為他們提供從瀏覽器到后台的 端到端全方位分析。感謝你跟着我一起完成了這個有點長的學習指南。歡迎給這篇博客留言，說說你在dynaTrace或者其他工具使用上的經驗。