http://www.sina.com.cn 2005年06月22日 09:12 天極yesky
運行測試并建立基線
要運行剛才建立的測試，只需要簡單地右鍵點擊該測試并選擇"開始測試"。測試開始以后，點擊"顯示詳細(xì)信息"按鈕。細(xì)節(jié)框中將顯示正在運行的測試的一個圖表，同時顯示在運行測試過程中可能出現(xiàn)的任何錯誤（圖5所示）。第一次運行這個測試建立了基線，我們可以把它與當(dāng)前的和未來的性能進(jìn)行對比。圖4顯示的基線是每秒大約90個請求。
圖4：基線圖表
現(xiàn)在你擁有了一個確定的基線了，你可以對應(yīng)用程序作一些修改以測量修改所引起的性能提升或降低。的確，我使用的測試示例極其簡單，但是我會顯示出對這一小段代碼進(jìn)行少量的修改可能對應(yīng)用程序的性能產(chǎn)生很大的影響。
了解改善的部分
評估的方面越多，改善的機會就越大。在例子中我將對應(yīng)用程序作一些小的修改，并在每個修改之后進(jìn)行評估。盡管在現(xiàn)實情況下你不可能每步修改都進(jìn)行這樣的測試，但是你應(yīng)該有周期性檢查性能的習(xí)慣。對于我們公司的Community Server產(chǎn)品，我們擁有一套用于評估總體應(yīng)用程序開銷的基線。如果進(jìn)行了重大的修改，開發(fā)者就可以使用前面的測試數(shù)據(jù)來研究性能的提升或降低。
我對示例應(yīng)用程序的第一處修改是改變返回數(shù)據(jù)量的限制。我把SQL查詢SELECT * FROM Products改變?yōu)镾ELECT TOP 25 * FROM Products。這好像只是對代碼進(jìn)行了微小的修改。畢竟我只是限制屏幕中輸出的數(shù)據(jù)量，但是其結(jié)果卻是驚人的。其性能從每秒90個請求上升到200以上--性能提高了100％以上。由于你擁有基線，你知道了限制綁定到數(shù)據(jù)表格的數(shù)據(jù)量一定會影響性能。我還要修改其它一些東西。
下一步，修改＜asp:DataGrid/＞服務(wù)器控件，添加EnableViewState="false"：
＜asp:DataGrid EnableViewState="false" id="DataGrid1" runat="server" /＞
ViewState是ASP.NET的一個重要的特性，但是并非總是需要的。實際上，大多數(shù)使用了ViewState的數(shù)據(jù)表格都是不需要它的。在例子中，通過禁止ViewState，我可以提高166％的性能。我們繼續(xù)！
下一步，添加下面的代碼以激活輸出緩沖（OutputCaching）：
＜%@ OutputCache Duration="60" VaryByParam="none" %＞
圖5：輸出緩沖
現(xiàn)在重新運行該測試。太驚人了！性能提高了600％，如圖5所示。你可以調(diào)整OutputCache的持續(xù)數(shù)值，例如把OutputCache的持續(xù)值設(shè)置為1秒--你可以看到性能再次有很大的變化。
建立測試環(huán)境
測試操作是CPU密集型的事務(wù)，因此在運行測試的時候，你可能看到CPU的占用率接近100％。它在與測試部件分享CPU時間的時候會拿走正在測試的應(yīng)用程序的資源。所有的配置選項都會影響測試結(jié)果，其中一部分模擬現(xiàn)實世界要真實一些。例如，如果SQL Server和ASP.NET在同一臺計算機上，就無法模擬網(wǎng)絡(luò)I/O的開銷。大多數(shù)應(yīng)用程序使用的數(shù)據(jù)庫都不在Web服務(wù)器上。
為了建立真實的測試環(huán)境，把大量的舊的用于開發(fā)的計算機作為客戶端使用。不要使用虛擬機。在這些計算機上運行Application Center Test。下一步盡可能地模擬現(xiàn)實世界。在一個沒有運行其它任何應(yīng)用程序的服務(wù)器操作系統(tǒng)上運行該Web應(yīng)用程序，并且連接到另一臺服務(wù)器的數(shù)據(jù)庫。
需要說明的是，在開發(fā)環(huán)境中運行"煙幕"測試也沒有什么錯誤。煙幕測試不能模擬現(xiàn)實世界，但是仍然可以提供大量的有價值的數(shù)據(jù)，并且可以用于預(yù)計在現(xiàn)實世界中同樣的測試產(chǎn)生的結(jié)果。
后續(xù)的步驟和測試覆蓋
現(xiàn)在你對如何測試和評估有了一些了解了，我推薦你在自己的應(yīng)用程序上使用Application Center Test。了解你的用戶在典型情況下如何使用應(yīng)用程序是有好處的：哪些頁面執(zhí)行得更好，哪些頁面沒有改善？
例如，在Community Server中我們運行了多種類型的性能測試。主線（Mainline）測試包含了匿名和驗證的情況。在大量個性化的應(yīng)用程序中這一點可能顯著的改變性能情況。
主線測試還包含了貫穿系統(tǒng)的通用路徑，例如網(wǎng)絡(luò)日志、圖表、論壇的主視圖，以及每個屏幕的不同視圖。很明顯，這些主線情形良好的執(zhí)行情況是非常重要的，最好在這兒花費大量的時間以確保其正確性。
如果你管理或運行那些必須支持兩個或多個并發(fā)用戶的項目，并且你不知道自己的主頁面每秒鐘可以處理多少個請求，那么就遇到問題了。
如果你擁有性能測試腳本，那么在每次重要的修改之后都應(yīng)該進(jìn)行評估。如果實際上是你自己構(gòu)造的代碼，那么就可以經(jīng)常深入源代碼并且評價各部分和重新編譯。這可以幫助你檢查出問題在于程序編寫得不好還是其它的原因。其它的原因有90％都出在數(shù)據(jù)訪問代碼部分。
你還可以測試應(yīng)用程序中的通用路徑。記錄測試的時候，只需要輸入用戶可能使用的通用導(dǎo)航路徑。Application Center Test將記錄下這些信息，并且你可以重新播放準(zhǔn)確的腳本。如果你喜歡，可以編輯生成的VBScript文件，給你的測試腳本引入延遲或其它有意義的輸入信息。
我推薦的最后的測試需要做很多工作。例如，在Community Server中我們的開發(fā)者希望測試應(yīng)用程序可以每分鐘可以支持多少個post（張貼）操作。為了測試它，我們不是把內(nèi)容寫入窗體，而是建立一個新ASP.NET頁面，它使用API來輸入內(nèi)容。接著這個頁面在Application Center Test中運行，應(yīng)用程序支持的每秒鐘張貼操作的數(shù)量就產(chǎn)生了。換句話說，有時候為了測試所有的情形，你可能需要多做一些工作。
結(jié)論
我沒有解釋Application Center Test提供的所有信息，但是我希望本文給了你足夠的使用Application Center Test的知識，這樣你才能夠使用它來評估和改善自己的應(yīng)用程序。請記住，建立基線、頻繁的評估（至少在每次重大的修改之后）并識別出關(guān)鍵的部分。遵循這些簡單的規(guī)則，你會對應(yīng)用程序有更好的理解，并且很有希望找到提高性能的機會。
[上一頁][1] [2]
點擊此處查詢
全部ASP.NET新聞
