作者： Mike Schelstrate 　來源： microsoft 

介紹

　　強度測試是Microsoft? Windows? DNA應用程序開發與推廣中常常被忽略的一個步驟，測試的目的是確保在實際環境中，最大數量的授權用戶對程序進行訪問時，該程序仍然能達到預期的性能。本文著重說明了對使用Microsoft Data Aclearcase/" target="_blank" >ccess Components (MDAC)開發的程序進行強度測試的重要性，給出了一些使測試過程更易于完成的技巧。

　　本文目的在于幫助熟練的開發員和IT專家設計一套完整的強度測試方案，執行后對結果進行評估，并提出對不足之處的修改建議，讀者應當熟悉Microsoft Windows NT? Server, Microsoft SQL Server?, Microsoft Internet Information Server (IIS), Active Server Pages (ASP), Microsoft ActiveX? Data Objects (ADO)和Microsoft Component Services environment (或 Microsoft Transaction Server [MTS]，如果使用的是Windows NT)

　　必須強調的一點是，在包括ADO的COM或DCOM組件中使用的商業邏輯和數據訪問過程一定要正確。出于性能和可靠性的原因，這些過程不可以駐留在Active Server Pages里。如果你關心應用程序在高強度下的使用情況，那似乎就表明你已經使用了這些組件來進行程序設計，也利用了Component Services 環境的優點。

　　本文不準備討論由客戶端瀏覽器或帶寬限制而引起的強度問題，而主要集中討論服務器端數據訪問組件和它們與Internet Information Server之間交互作用所引起的強度問題，對于使用Remote Data Services (RDS)所引起的問題也不予討論。

　　為什么要對應用程序進行強度測試？

　　在應用程序正式推廣到生產環境中進行使用前，常常需要進行強度測試，對網絡應用程序進行強度測試是要達到如下的幾點基本目的：

　　雖然對于絕大多數Web應用程序來說，用戶的體驗是決定該程序是否成功的最主要因素，但是，仍然有很多充分的理由需要你對程序進行強度測試，包括以下幾條：

• 開發階段運行良好的程序，在高強度的環境中，性能有可能變得很差。例如，Internet Information Server 或SQL Server 會被多個程序同時使用，如果沒有為讓程序在這種情況下能正常工作而進行很好地設計的話，那么執行新程序將可能影響，甚至中斷已經在運行各個程序。
• 用戶最初幾次使用應用程序的情況將給他們留下最為重要的印象。如果因為強度問題導致印象不佳，那么即使你解決了這些問題，也很難再改變他們的看法。反過來說，如果在推廣應用程序前進行了足夠的強度測試，你所開發出來的優良快速的程序能按照預想的方式運行，你就能在用戶中樹立了一個良好的開發員的形象。
• 負責對應用程序進行推廣與維護的IT工作組，對你所進行的強度測試，將和你的客戶一樣甚至比他們更加予以贊賞。他們處在第一線，你首先聽到他們的意見和使用結果，如果你可靠地預計了程序的彈性問題，就會對IT工作組起很大的影響，在你需要他們的經驗時，組里的成員將非常樂意向你提供幫助。
• 用戶滿意矩陣還應當包括潛在的商業伙伴，如果他們決定將你的程序納入更大的程序包中，將使程序取得更大的成功。

　　強度測試的準備

　　為了確定最佳服務器的分析值，也就是基準，首先要在受控環境下對引導系統的配置進行測試，然后在一個模擬的工作環境中進行測試，確定工作環境中的配置將對引導系統產生怎樣的影響。

　　在程序開發過程中強度測試的準備中，應當注意以下幾個方面；

• 硬件和軟件的配置
• 服務器配置
• 安全性設置
• 用戶負荷的設置
• 選擇合適的強度測試工具

　　硬件與軟件的配置

　　引導系統必須盡最大可能反映實際系統的情況。CPU，RAM和網絡帶寬這些硬件的配置是強度測試中最為重要方面，同樣也要盡可能再現軟件的配置，如Microsoft Windows、服務包(service pack)和MDAC各自己的版本，Internet Information Server配置和其他實際系統中各種將在同一臺機子上運行的程序都應當一樣。安裝并注冊中間層的商業規則和數據訪問COM組件，按照程序設計的要求進行配置。

　　最后一項設置是確定在進程中還是進程外運行即將進行測試Web站點。這一選擇將決定你的Web應用程序是運行在與IIS相同的還是單獨的地址空間。該設置對要進行的強度測試有很重要的影響。下圖所示的是Microsoft Windows NT 4.0 和 Microsoft Windows 2000中 Stress Properties 屬性頁的設置。在Microsoft Windows NT 4.0 中，選擇 Run in separate memory space (isolated process) 復選框使Web應用程序運行于進程之外。

在Windows 2000中，則將 Application Protection 選項設為 Medium 或 High 來使Web應用程序運行于進程之外。

圖一。Windows NT 4.0 的Stress Properties 屬性頁

圖二。Windows 2000 的Stress Properties屬性頁

　　服務器配置

　　配置Internet Information Server來模擬實際中的服務器。 Internet Services Manager 屬性頁提供了對IIS進行調整各個選項。較為重要的是要決定是否激活日志選項（激活這一選項將明顯地降低系統運行速度），另外要在 Performance 標簽里選擇每天預期的點擊數。

　　多數有待解決的與強度有關的問題存在于數據服務器上。為了更有效地執行查詢過程，有必要對數據庫的設計進行適當的正規化，所以進行強度測試的數據庫必須與程序實際將要使用的相同，同時要保證表格集中在程序將要生成的最大數量的數據上。另外還要確保進行測試的數據服務器的配置選項與實際中的相一致（尤其是鎖定與隔離層以及使用的優化技術—例如表格索引）
安全性設置

　　應用程序的安全性方案對處于高強度下的程序有相當嚴重的影響，特別是假如這個系統使用了例如Microsoft Cryptography API加密技術的話。所以你必須為有待測試的系統設置相同的安全性方案，但不一定需要相同的證書。關于在intranet中對終端存儲數據進行訪問的應用程序的安全性協議，最常用的大概是Microsoft Windows NT LAN Manager (NTLM)認證體系。如果可能，你應當考慮使用Component Services (或Windows NT 中的MTS)來簡化與合理化安全認證過程，并增強系統的性能和穩定性。

　　用戶負荷的設置

　　首先確定你所期望的訪問此程序用戶的最大數量，然后加倍；一個成功的應用程序非?？赡軙斜阮A期的要多得多的用戶。然后，計算一天中大多數用戶將進行訪問的時間，確定那段時間內網絡的負荷，這也就是你將進行測試的時間。這一策略使得你能對用戶負荷的影響和系統硬件的配置進行測試，以保證程序在網絡高峰期也能有預期的響應。

　　選擇合適的測試工具

　　在實際數據中心的環境中，由于有大量的用戶將經由公司的intranet或Internet來連接Web程序，所以Web服務器將處于很高的連接水平上。Web程序強度測試的工具應當在控制發送給Web服務器數據包大小的同時，有足夠的線程數來最大化并行連接數，這樣才能夠模擬出很高的并行連接數量。幸運的是現在有許多工具都可以模擬出這樣精確的環境。其中的一種就是Microsoft的Web Application Stress Tool，可以免費地從Microsoft 的http://webtool.rte.microsoft.com/ 站點獲得，它提供了所有必需的功能，還有一些附加的優秀功能，比如多種記錄特征。

　　Web應用程序強度測試工具

　　Web Application Stress Tool真實地模擬大量瀏覽器向web程序提出頁面請求的過程，創造測試環境，同時也將瀏覽器所訪問的希望在測試中包括的頁面記錄在一個腳本程序中。這一腳本程序可以保存下來，然后在安將了此應用程序的Windows NT 或 Windows 2000 客戶機上運行。由于Web Application Stress Tool 能夠在單獨的一臺工作站上模擬大量的用戶，所以測試時并不需要與實際中同樣多的客戶機。

　　注意 當你進行強度測試時，請注意不要提高客戶機的強度水平，因為那樣的話，進行測試的機器將在線程的轉換上花費大量的時間，而不是在真正地進行工作。當對一個基于Web的應用程序進行測試時，應多使用幾臺客戶機，以保證線程分布于各臺客戶機上，從來降低對每一臺客戶機資源的要求。

　　性能監控器

　　要想對數據訪問組件進行有效的測試及正確分析所得的結果，最為重要的就是要有一套對運行信息進行監視和記錄的方法。Microsoft Windows NT 和 Microsoft Windows 2000附帶的Performance Monitor，就是現成的對種信息進行監視和記錄的工具，它對Internet Information Server和數據服務器都是適用的。

　　其他工具

　　除了在Internet Information Server上運行Performance Monitor以外，還應當注意數據服務器上自帶監視器。許多高性能的數據服務器應用程序，例如Microsoft SQL Server, Oracle 和 Microsoft Exchange Server都帶有自帶的性能監視器，可以利用它來衡量程序和運行此程序的硬件的穩定性。

　　進行強度測試

　　當認真地制定好測試方案后，實際進行測試的過程是很簡單的。性能測試的第一步是使用類似Microsoft Web Application Stress Tool的工具對Web站點進行強度測試，測定Web服務器每秒種所能處理的最大請求數，這是定量的測量。第二步確定CPU，內存或終端設備中哪一項限制了每秒請求數達到更高的水平；這個過程與其說是一門測量技術，倒不如說是一門藝術。
先選擇你計劃運行的ASP頁面(尋找并使用站點上最慢的頁面)，這要根據訪問數據庫最頻繁和查詢量最大最復雜的頁面來確定。這一點非常重要，最好是寧可包括一些不在這之內的更多的頁面，也不要遺漏一些關鍵的代碼路徑。另外如果有可能的話，可以考慮象實際中一樣，按照特定的順序訪問一系列頁面，將cookie和查詢字符串傳遞到每個頁面來測試程序。

　　注意 根據實際程序的不同，可能有必要為測試準備一些ASP頁面。其中的一些頁面會需要通常由應用程序生成的代碼參數，這些參數Web強度測試工具是不能生成的。

　　在Internet Information Server上運行程序時，應當對下列指標進行監測（用Performance Monitor）。

• Active Server Pages :每秒請求安息，被拒絕的請求數，總隊列長度和當前對話數
• Inetinfo 進程 : 私有字節，虛擬字節和打開的句柄數量
• 處理器 : 用戶使用時間和特許時間百分率的比值

　　注意 如果程序在Windows NT 4.0下運行于獨立的內存中(或在 Windows 2000中將 Stress Properties 頁的 Application Protection 設為 High [Isolated] )，就應當監測mtx.exe(在Windows 2000 里是dllhost進程)而不是Inetinfo進程。

　　如下圖所示；Performance Monitor里每秒Active Server Pages請求數將顯示程序的實際吞吐能力（在本例中是 1.000 Requests/Sec ），這一數據使得你能對高強度下Internet Information Server的性能進行分析，然后找到潛在的瓶頸的精確位置。反過來也使你可以判斷程序在可接受的響應時間下，所能承受的最大用戶數。

圖三。性能監控器

　　使用ASP技術的Web服務器在啟動時，從已經建立的大量線程中為每個頁面請求都指定一個線程;如果所有的線程都已經被使用了，就將后續的頁面請求排在隊列中。在Performance Monitor中對總隊列長度進行監視，可以確定有多少客戶在等待服務器的響應。

　　最為常見的兩個關系到數據庫強度性能，與硬件無關的問題就是死鎖和并行鎖定。在數據服務器上使用數據存儲器自帶的Performance Monitor監視器時，至少應當對下列各指標進行監視。

• 鎖定請求
• 每秒死鎖數
• 每秒運算表格鎖定的增加
• 用戶連接
• 正在進行的處理

　　Web應用程序的設置同時也應該利用到OLE DB 資源合并的優點，這個應用程序由中間層OLE DB provider for Microsoft SQL Server 7.0自動進行管理的。先創建每一頁面基礎對象的連接，然后立即釋放它們，通過這一方法，可以用很少的打開數據庫的連接，處理成千上萬個并行用戶，這樣就保護了數據庫的資料，也提高了穩定性，這個增強的性能要用跟蹤數據服務器上用戶連接數的方法來進行監測（使用Performance Monitor）。當訪問量增大時，用戶連接數應該保持穩定，因為資源合并控制了在數據服務器上實際生成的連接數。

　　要達到預期的性能，依據數據庫對程序進行調試的過程是非常關鍵的，所以必須作為開發周期的一個重要環節。這一過程包括對分配內存的大小，程序在各磁盤驅動器和控制器上分布，以及ActiveX組件的機器位置進行優化。只要有可能，就特別應該考慮消除進程之間數據的排隊問題，因為這會占用非常大的運算量。

　　運行測試的時間，應是預期的實際用戶環境中程序連續運行時間的一半以上。許多問題，尤其是內存不足，只有當程序運行了較長的一段時間后才會出現。
測試中應尋找的問題

　　Performance Monitor中每個指標的平均值是由程序與硬件的配置共同決定的。所以進行測試的時候，應當注意每一個指標是否偏離了平均值。

　　監測Internet Information Server

　　在尋找系統瓶頸時，Internet Information Server上最需要進行監測的是下面各項：

• CPU利用率
• 內存使用情況
• 吞吐能力

　　在測試過程中，根據設計的程序運行的不同環境，會想要跟蹤其他的一些性能指標，這些都是可以選擇的。程序出現下面任何一種的情況，都表明可能存在問題，需要在最終發布前予以修正。

　　CPU 利用率

　　CPU使用的下降表明程序的性能有下降，這可能是由線程沖突問題引起的

　　在對CPU的用戶使用時間與內核使用時間的比值進行監測時，請記住用戶的使用時間應當占到CPU總使用時間80--90%這條規則。所以內核使用時間超過20%就意味著內核層的API調用指令有沖突。

　　為了讓你對機器的投資有效地得到利用，應使CPU的利用率在負荷達到峰值時超過50%。如果低于這個值，表明在系統其他地方還有需要解決的瓶頸問題。

　　內存使用情況

　　長時間運行服務器程序后，內存使用出現突躍或緩慢增長也是常見的一個問題，這是正常的在測試階段暴露出來的資源不足問題。

　　吞吐能力

　　監視Active Server Pages每秒請求數這個指標，能夠診斷出程序是否或何時開始出現性能問題。實際環境中這個數值會出現正常的波動，但是小心地設定線程與并行連接的數量（如在Web Application Stress Tool進行設置）可以模擬出一個穩定的請求數。這個數值的突然降低也說明有問題存在。

　　選擇性測試

　　下列是在測試過程中，其他一些值得進行監測的指標

• 總隊列長度 . Performance Monitor中總隊列長度都會上下波動，這是很典型的。所以如果CPU使用率很低，而總隊列長度卻始終沒有增加，就表明這是一個運行很平穩的站點，它的能力比此負荷所要求的還高出不少。但是，如果總隊列長隊在上下波動，而CPU的使用率低于50%，那就表明有些請求被阻滯了，需要對程序進行更進一步的優化。
• 瀏覽器響應時間 . 你可以定期的用瀏覽器訪問Active Server Pages監測響應時間，保證測試正在正常地運行和Web站點仍然能正常地提供ASP頁面服務。建議在整個強度測試過程中每天至少進行兩次。
• 超時錯誤 . 在瀏覽測試中要注意Internet Information Server返回的超時錯誤；這些錯誤可能說明有過多的用戶在同時對程序進行訪問。

　　監測數據服務器

　　數據服務器內部的各種MDAC服務和顯示數據的格式化過程，通常都占據了絕大部分Web程序所使用的服務器資源。因此在對程序進行強度測試的時候，對這些組件的性能給予特別的關注是必要的，因為它與程序中數據訪問和操作部分是聯系在一起。

　　數據庫的用戶連接，鎖定沖突與死鎖是數據服務器上需要監測的主要幾個候選參數。定期對數據庫控制臺中的進程信息進行檢查（例如SQL Enterprise Manager中的 Current Activity ），查找受到阻滯的服務器進程ID，這是一個引起數據查詢沒有響應的常見原因。它是一個沖突問題，通常要對數據庫設計或程序邏輯做很大的調整才能解決。

　　死鎖問題可以用很多方法認定。最常用的是在Performance Monitor里通過 Number of Deadlocks/sec 的數值來認定。程序的死鎖問題必須經過檢查，而且要做到能夠正常響應才行，因為如果由數據服務器來確定死鎖的承受者（即為了解決死鎖而被取消的用戶或對話）將使程序有很大的毛病。在出現死鎖時，程序應能自行能檢測到，并做出相應的對策來解決問題，通用的方法是等待幾毫秒后再次進行操作，一般來說，死鎖都是對時間敏感的錯誤，重試就能夠消除問題。
評估強度測試結果

　　強度測試結束后，對目標值與測試中獲取的數據進行比較，可以找到為了滿足用戶的需要而應當做的一些修正。下列是為性能修正而要檢查與評估的各個項目，

• 硬件
• 數據庫的設計
• ActiveX組件
• 客戶端游標
• ASP的執行
• IIS負荷

　　硬件

　　硬件升級大概是提高程序能力的一個最簡單最低廉的解決方案。硬件升級比聘用一組開發員對程序進行重寫要經濟的多，比如只要增加內存就可以很方便地將程序的吞吐能力提高一倍。但是如果測試結果表明CPU使用是系統的瓶頸，那么升級的費用會相當昂貴，因為幾乎整臺機器都要升級，才能達到CPU數量和速度增加。

　　其它一些與硬件升級包括提高硬盤和控制器的速度，以及加上更快或額外的網卡。

　　數據庫設計

　　如果評估出的結果與數據庫的設計有關，則先尋找熱點。分析死鎖的數據，確認程序已經做了最大程度的優化避免死鎖。必要時要考慮改變數據訪問邏輯來解決沖突。試驗不同的索引方法。檢查數據服務器的查詢執行方案，確認查詢使用了正確的索引，等等。

　　ActiveX組件

　　優化引用了ActiveX Data Objects類型庫的ActiveX組件必須小心地進行分析。不要使用ADO的默認屬性。始終都指定屬性以防止偶然情況的發生，例如 Cursor Type 和 Cursor Location 屬性。

　　客戶游標

　　如果Web應用程序占用了異常大量的內存，這個問題可能是由游標位置的不正確造成的。當使用客戶游標時( recordset.cursorlocation = adUseClient )，先了解客戶端確實是Internet Information Server而不是瀏覽器。（這種情況的特例是Remote Data Services，不在本文討論范圍）。開發員常犯的錯誤是假定客戶游標在瀏覽器而不是IIS的整個數據組中移動。因此，牢記數據組實際上是存儲在運行IIS的機器上將讓你有意識地注意對資源的合理利用。

　　比如，程序要存取一張有效的州或國家代碼，而這些信息都存儲在數據服務器上，利用客戶游標生成一個數據組并駐留在IIS上，然后在當地訪問這些代碼的效率會更高，這樣可以避免程序對這些信息訪問時，數據服務器上額外的信息往返。

　　ASP的執行

　　如果有數據存取過程的ASP頁面需要很長時間來運行，就有必要將這些數據存取的代碼轉移到ActiveX組件中去，更可行的辦法是放在Microsoft Transaction Server (Windows NT) 或 Component Services (Windows 2000)所帶的軟件包里，這取決于你使用的系統。這些編譯過的代碼的運行效率要比Active Server Pages所包含的解釋腳本的代碼快很多。

　　Internet Information Server負荷

　　監測使用Internet Information Server的程序數量與類型。你可能需要增加更多的服務器，將程序轉移到另一臺服務器上運行或執行Windows Load Balancing Service

　　成功執行強度測試的技巧

• 應當
  • 將所有的商用邏輯放在ActiveX組件里，用ASP頁面將它們聯系起來，把可以再使用的代碼封裝到庫內。
  • 使用MTS(Windows NT 用戶)。這是一個強大的為服務器端COM對象提供額外線程和資源合并，并輕松對這些對象進行管理的工具。另外MTS還提供了事件處理能力。
  • 使用資源/連接合并。MDAC的這一特性是默認的，但是應當對其進行監測以保證運行正常。
  • 調試數據存儲。在合適的位置調用存儲程序。
  • 用輸入、輸出和數據轉換的緩存來最小化數據訪問的操作量。
  • 只要有機會就使用進程內程序和ActiveX組件
  • 確保實際工作時是不允許進行調試的。調試程序會強制轉移線程。
  • 在intranet環境里，如果可能的話可以將一些工作量轉移到客戶瀏覽器上。
  • 升級到Windows 2000。對程序進行強度測試時，新發布的Windows 2000性能與可伸縮性的增強立刻就能感覺出來。
  • 如果你一時之間無法升級到Windows 2000，至少升級到Microsoft Visual Basic? Scripting Edition (VBScript) 5.0也是一個不錯的辦法，新版本的性能與功能也得到了明顯的增加。
  • 考慮使用Microsoft Message Queue Server (MSMQ)。合理地使用異步信息傳遞可以顯著增大能處理用戶響應的次數。
• 不要 :
  • 在Active Server Pages內使用程序或對話層對象
  • 在Active Server Pages放置數據訪問代碼。用腳本代碼來和ActiveX組件內的數據訪問函數與商用邏輯進行通信。
  • 在不是絕對必須的時候使用HTTPS/Secure Sockets Layer。這一認證協議執行時的代價是非常昂貴的。
  • 不必要的使用程序或對話狀態。

　　總結

　　Internet使你的程序比傳統的客戶-服務器方式程序有更多的潛在用戶。越來越多的組織意識到網絡是他們商業戰略的一個重要組成部分，所以他們選擇的技術要能夠應付巨大的需求。這些組織不光要有易于使用的工具，還要有能滿足他們用戶負荷的基礎設施。因此較之以往，強度測試更應該成為一個很重要的步驟，尤其是當你在程序中包含了MDAC的時候。

　　注意 在開發環節中用最優法，是使系統在高強度下成功運行的一個基本要求。這就是說，在開發過程中，有負荷下的性能測試和為達到性能要求而進行的調試都要排進日程表。

　　進行強度測試和在有負荷下對程序反復調試的好處是顯而易見的；

• 可以獲得所需的確保程序有足夠吞吐能力的信息。
• 可以精確了解程序的可伸縮性信息，從而調試程序達到所需的性能要求。
• 可以在實際推廣前，及早發現降低性能的吞吐能力的設計問題并做出修正。
• 由于程序的高性能，可以在用戶和商業伙伴中贏得良好的聲譽。