【51CTO獨家特稿】51CTO開發頻道推出系列文章《VS2010分布式和異構應用程序的負載測試》，點擊這里查看上篇。

對每個失敗的Web請求顯示PurePath

在VS2010負載測試運行設置（Run Configuration）中，你可以指定把詳細的反應結果存儲在一個SQL數據庫中。這使得你在負載測試完成之后，可以查找單個失敗的事務處理，包括實際的HTTP流量以及所有相關的時間。在我的測試中就有另外一個較慢的事務處理，名字叫BuyDirect。我通過VS2010 Load Testing Report打開了那些失敗的事務處理，并對那些速度慢的請求進行了分析：

負載測試的問題請求，連接到dynaTrace PurePath

結果視圖（result view）告訴我，這個請求用了1.988秒。dynaTrace VS2010插件在Results Viewer中添加了一個新的標簽，點擊一個PurePath連接就可以打開捕獲的PurePath來查看那個特別慢的請求。點擊這個連接會在dynaTrace Client中打開PurePath：

 從Visual Studio打開的長時間運行的異構事務處理

我們能很容易的發現在這個事務處理中時間都花在了哪里---都花在了從第二個JVM (GoSpaceBackend)到承載Web Service (DotNetPayFrontend)的CLR的網絡服務調用上。其中一個問題似乎也跟調用網絡服務時發生的異常情況有關。這些異常情況不能構成我們自己的日志架構，因為它們是由Axis內部處理的，但是它們會由配置問題引起（我們可以去查看完整的異常堆棧跟蹤來查明事實）。進一步往下點擊，我可以看到這個處理的Sequence Diagram程序流程圖。這個流程圖更好的描述了4個不同服務器之間的交互活動：

dynaTrace程序流程圖，顯示了在單個事務處理中服務器之間的交互活動

程序流程圖的內容比截圖中內容豐富得多，但我猜你已經知道，我們已發現了一個服務器之間交互率非常高的事務處理。

dynaTrace VS2010 Plugin讓我在幾秒鐘之內就找到了分布式異構事務處理中存在著問題的方法，比單獨依靠負載測試報告來分析這個問題節省了大量的時間。

跟開發人員分享測試結果，并在源代碼中找到問題的出處
現在，我們已經擁有了所有重要的信息，并且已經發現了幾個開發人員應該仔細調查的熱點問題。我只是簡單的把捕獲的數據導出到一個dynaTrace Session文件中，并把它附在一個我指派給開發人員的JIRA文檔上面（或其他bug追蹤工具），而不是讓開發人員來訪問我的測試環境。我也可以導出所有捕獲的數據，或者更明確的說，只導出那些被識別出來的有問題的PurePaths。

開發部門拿到dynaTrace Session文件之后，會將其導入到自己的本地dynaTrace Client中，并分析我們在測試環境中已經分析過的那些相同粒度(same granular)的數據。安裝dynaTrace Visual Studio 2010 Plugin之后，開發人員可以從PurePath中或者dynaTrace Client的Methods Dashlet中開始查找Visual Studio中的單個方法：

查找問題方法的源代碼

Visual Studio的dynaTrace Plugin插件會對所選擇的方法進行搜索、打開源代碼文件，并把光標放在那個方法上，但前提是你必須保持你的解決方案文件是打開的：

在Visual Studio 2010編輯器中顯示出問題方法的源代碼

你可以很容易把這些數據跟需要研究它們的人進行分享。在短短幾秒鐘內，開發人員就可以在Visual Studio 2010中找到那行有問題的、影響性能的源代碼。開發人員還可以查看所有的背景資料，它們可以顯示出為什么同一個事務處理的單個執行比其他的要快，因為PurePath包含諸如方法參數、HTTP參數、帶有Bind變量的SQL語句、Exception Stack Traces等信息，所有這些信息都是開發人員所喜歡的。

通過測試運行來識別回歸（Regressions）

當針對不同的build版本連續運行負載測試時，我們期望其性能會越來越好。但是，如果情況不是這樣呢？上一個build版本到目前的版本都有哪些改變？哪些模塊的表現不如上一個版本中的好？我們訪問數據庫的方式變了嗎？自定義代碼的算法是否用時太多，或者引入到這個build版本中新的第三方庫是否讓所有操作的速度都變慢了？

Automatic Session Analysis 插件還能分析在兩個負載測試會話之間傳遞的數據，并產生一個報告，顯示出這兩個會話的不同之處。下面的屏幕截圖顯示了一個負載測試的回歸分析結果：

 通過比較兩個負載測試會話得到的回歸分析

上圖顯示了***版本（左上角）以及上一個build版本（右上角）中實際執行了哪些處理。在窗口的中間，我們可以看到每個會話中哪些層/模塊消耗了系統性能，還有一個并列的對比（中央），那些時間條告訴我們哪些模塊執行得更快或者更慢。我們似乎在大多數模塊中都存在著某些嚴重的性能降低。在底部，我們還看到一個已執行的數據庫語句與方法的比較。就像我在上一節中所說的那樣，我們可以通過這個報告掌握更多的細節，進而對更多的細節進行分析。

總結
Visual Studio 2010是針對.NET或者Java網絡應用程序執行負載測試的一個好工具。在這個版本中，Load Testing Report（負載測試報告）已經得到了改進，你可以對應用程序的性能有一個更好的理解。對于多層或者異構應用程序來說，正如我以上使用的那種，現在通過一個像dynaTrace這樣的應用程序管理方案就能很輕松的獲得比標準負載測試報告更多的信息。把負載測試方案以及APM方案結合起來使用，不僅能幫助你發現性能問題，還可以讓你更快的找出問題所在，從而減少了測試周期以及測試階段所花的時間。

如果你對這些話題感興趣的話，這里還有更多的資料供你參考：關于怎樣進行自動負載測試以及問題分析的白皮書；與Novell和Zappos一起進行的網絡研討會，討論將負載測試方案和dynaTrace結合起來使用，從而加速測試過程；還有一些相關的博客文章（名字叫做101 on Load-Testing）可以參考。

原文標題：VS2010 Load Testing for Distributed and Heterogeneous Applications powered by dynaTrace

【編輯推薦】

1. Visual Studio 2010將再度擁抱UML
2. 圖解Visual Studio 2010中的UML建模功能
3. Visual Studio 2010及.Net 4新功能一覽
4. Visual Studio 2010安裝初體驗
5. Visual Studio 2010中調試.NET應用程序詳解