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