【51CTO獨家特稿】Visual Studio 2010已經(jīng)來臨了，看起來相當不錯。微軟給其性能管理方案（比如dynatrace）添加了新的界面，用來擴展網(wǎng)絡測試以及負載測試的能力（請查看Ed Glas的日志，里面介紹了VSTS Load Testing中有哪些內(nèi)容），以超越.NET的開發(fā)環(huán)境，并且比負載測試報告更能深層次的告訴你關(guān)于被測試應用程序的性能。51CTO開發(fā)頻道向您推薦《VS2010分布式和異構(gòu)應用程序的負載測試(下)》

但是，在我們探索通過擴展Visual Studio能做什么之前，讓我們看看沒擴展時我們能得到哪些東西：

Visual Studio 2010的標準負載測試報告

Visual Studio 2010運行負載測試是為了收集各種各樣的信息。這些信息包括執(zhí)行要求的反應時間、被測應用程序基礎設施（比如CPU，內(nèi)存，I/O, …）的性能計數(shù)器，以及你的負載測試基礎設施（負載控制器及代理）的健康程度。我運行了一個4層（2個JVM, 2個 CLR）的網(wǎng)絡應用程序。4個層通過SOAP Web Services (Axis->ASMX)進行交流。這個前端網(wǎng)頁應用程序是用Java Servlets實現(xiàn)的，在15分鐘的測試中負載不斷增加。測試分為多個不同的事務處理，比如：Home Page、Search、Login、BuyDirect等…---當運行測試的時候，我也同時監(jiān)視了所有相關(guān)應用程序服務器以及負載測試基礎設施的性能計數(shù)器。Visual Studio 2010 允許我通過可配置的曲線圖來監(jiān)視負載測試的當前狀態(tài)，具體曲線圖如下所示：

Visual Studio負載測試曲線圖

該圖顯示，隨著用戶負載的增加，我的事務（不是全部）處理的反應時間也在增加。圖中還顯示出應用程序服務器上的CPU使用率出現(xiàn)了問題（同時有差不多20個用戶時，CPU的使用率就會超過80%）。在負載測試的最后，會有一個總結(jié)報告，描述了對于這個應用程序執(zhí)行了哪些負載---發(fā)生了哪些錯誤以及哪些頁反應最慢：

負載測試總結(jié)報告

把報告切換到表格視圖，會有一個單個結(jié)果特征的詳細分類，比如Transactions、Pages、 Errors（事務處理，頁，錯誤，）等等：

Visual Studio負載測試匯總表格

從表格試圖中我們可以得到以下結(jié)論：

 553頁的請求超過了我的每頁200ms規(guī)則

 553頁是屬于menu.do, netpay.do 以及 userlogin.do（當你查看單個錯誤請求的時候，你就可以看到這個）

 該LastMinute事務處理是目前最慢的，平均反應時間1.41秒，最大反應時間為5.64秒。

我們不知道的是這些事務處理為什么這么慢：性能計數(shù)器表明CPU是一個潛在的問題，但是它沒有告訴我們，是什么造成了CPU負載增大，這個問題是否能被解決或者說我們是否已經(jīng)達到了系統(tǒng)性能的上限。

dynaTrace捕獲的Visual Studio 2010負載測試執(zhí)行情況報告

dynaTrace用戶可以從dynaTrace Community Portal（dynaTrace社區(qū)門戶）下載這個Visual Studio 2010插件。這個程序包里含有一個Visual Studio外接程序以及一個Visual Studio測試插件庫，擴展了其網(wǎng)絡測試以及負載測試的能力。我們也提供Automatic Session Analysis（自動會話分析插件），能夠幫忙分析從較長時間的負載測試中捕獲的數(shù)據(jù)。

在我的4層應用程序中進行負載測試時，我使用的是dynaTrace Test Center Edition（測試中心版）。這個Visual Studio 2010插件確保了dynaTrace能夠自動捕獲所有dynaTrace會話中的服務器端事務處理（PurePath的）。它還確保那些跟Web Test腳本中名字相同的事務處理都會傳遞到dynaTrace。

在運行負載測試過程中，我創(chuàng)建的Load Testing Performance Dashboard（負載測試性能儀表板）使得我可以觀察傳入的請求以及每個JVM和CLR中的內(nèi)存使用情況。我能看到我的應用程序中是哪些層次對系統(tǒng)的性能產(chǎn)生了影響--- ADO.NET, ASP.NET, SharePoint, Servlets, JDBC, Web Services, RMI, .NET Remoting等等層---dynaTrace會自動監(jiān)測這些層，而且還幫助我理解應用程序中實際上是哪些部件/層次消耗了大部分的執(zhí)行時間以及逐漸增加的負載對這些部件的影響分別是怎樣的。除此以外，我還能觀察到執(zhí)行的SQL語句數(shù)量（不管是通過Java還是.NET），以及發(fā)生的異常情況的數(shù)量：

dynaTrace負載測試性能儀表板

儀表板左上角的圖表中顯示的是單個事務處理的反應時間，其下方的圖表是累積的事務處理數(shù)量。這些是進入的請求數(shù)量，從中我們很容易獲悉VS2010是怎樣在測試中增加負載的。

儀表板右上角的圖表是兩個JVM的內(nèi)存使用情況，其下方的圖表是兩個CLR的內(nèi)存使用情況（在我的第二個JVM中似乎存在著一個內(nèi)存泄漏，而且還有一個非常“安靜的”CLR）。

儀表板左下角的圖表顯示的是我的應用程序隨著逐漸負載的增加有什么變化。我能看到我的應用程序表現(xiàn)一直都還不錯，直到一個特定的用戶負載得出現(xiàn)。但是，Web Service Layer（網(wǎng)絡服務層）（黑灰色）的性能表現(xiàn)開始比其他所有有關(guān)的應用層差很多。

儀表板右下角的數(shù)據(jù)庫語句數(shù)量以及異常情況數(shù)量告訴我，這些計數(shù)器隨著負載的增加而線性的增長。但是，似乎我們有相當多的數(shù)據(jù)庫查詢（高達350/second），還有非常多的異常情況值得調(diào)查。

在負載測試完成之后，我得到的第一個報告顯示出速度最慢的網(wǎng)絡事務處理，它們按照Visual Studio中的名字進行歸類：

dynaTrace每個網(wǎng)絡處理的性能報告

從上圖中，我可以看到LastMinute處理的確是最慢的處理，反應時間5.6秒是最大的。從這個報告中，我們能夠?qū)⒏呒壥聞仗幚矸纸獬蓱脤?、?shù)據(jù)庫調(diào)用以及方法調(diào)用，從而進行細致的分析，這是該報告的最大優(yōu)點所在。根據(jù)這個分類我們能夠立即看出對于Last Minute處理來說，Java Web Service是最高的性能消耗者。我們也能看到448個對此事務處理的請求包含有幾千個數(shù)據(jù)庫查詢，我們還能看到是哪些Java以及.NET方法占據(jù)了系統(tǒng)的執(zhí)行時間。點擊Slowest Page會打開PurePath Dashlet，它顯示出每個已執(zhí)行的事務處理。如果按持續(xù)時間進行排列，還可以顯示出各個處理的執(zhí)行時間有著巨大的差異。PurePath Hot Spot視圖讓人很簡單的就能揪出在最慢的事務處理中最消耗性能的方法：

 運行最慢的事務處理中，不同的PurePath之間差別很大

有了PurePath Comparison功能，我可以進一步找出兩個執(zhí)行時間差別很大的事務處理有什么不同：

通過可視圖表以及PurePath Comparison Tree，我們可以看到時間上的區(qū)別主要是因為在該情況下進行SpecialOffer和所有調(diào)用構(gòu)成的。底部的表格列出了這兩個PurePath之間所有時間和結(jié)構(gòu)的不同之處，讓我們更加深入的了解還有沒有其他方面的差別。

原文標題：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中調(diào)試.NET應用程序詳解