【51CTO獨(dú)家特稿】51CTO開發(fā)頻道推出系列文章《VS2010分布式和異構(gòu)應(yīng)用程序的負(fù)載測試》，點(diǎn)擊這里查看上篇。

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

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

負(fù)載測試的問題請求，連接到dynaTrace PurePath

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

 從Visual Studio打開的長時間運(yùn)行的異構(gòu)事務(wù)處理

我們能很容易的發(fā)現(xiàn)在這個事務(wù)處理中時間都花在了哪里---都花在了從第二個JVM (GoSpaceBackend)到承載Web Service (DotNetPayFrontend)的CLR的網(wǎng)絡(luò)服務(wù)調(diào)用上。其中一個問題似乎也跟調(diào)用網(wǎng)絡(luò)服務(wù)時發(fā)生的異常情況有關(guān)。這些異常情況不能構(gòu)成我們自己的日志架構(gòu)，因?yàn)樗鼈兪怯葾xis內(nèi)部處理的，但是它們會由配置問題引起（我們可以去查看完整的異常堆棧跟蹤來查明事實(shí)）。進(jìn)一步往下點(diǎn)擊，我可以看到這個處理的Sequence Diagram程序流程圖。這個流程圖更好的描述了4個不同服務(wù)器之間的交互活動：

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

程序流程圖的內(nèi)容比截圖中內(nèi)容豐富得多，但我猜你已經(jīng)知道，我們已發(fā)現(xiàn)了一個服務(wù)器之間交互率非常高的事務(wù)處理。

dynaTrace VS2010 Plugin讓我在幾秒鐘之內(nèi)就找到了分布式異構(gòu)事務(wù)處理中存在著問題的方法，比單獨(dú)依靠負(fù)載測試報告來分析這個問題節(jié)省了大量的時間。

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

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

查找問題方法的源代碼

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

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

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

通過測試運(yùn)行來識別回歸（Regressions）

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

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

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

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

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

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

原文標(biāo)題：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安裝初體驗(yàn)
5. Visual Studio 2010中調(diào)試.NET應(yīng)用程序詳解