對 Windows DNA 應用程序中的數據訪問組件進行壓力測試

內容

介紹
為什么要對應用程序進行javascript:;" onClick="javascript:tagshow(event, '%D1%B9%C1%A6%B2%E2%CA%D4');" target="_self">壓力測試？
準備運行壓力測試
運行壓力測試
計算壓力測試結果
成功運行壓力測試的提示
結束摘要

介紹

Microsoft? Windows? DNA 應用程序的開發和部署中經常被忽略的步驟是對應用程序進行壓力測試，確保當生產環境中最大數量的授權用戶訪問該應用程序時，它將按預期執行。本文強調當涉及使用 Microsoft Data Access Components (MDAC) 開發應用程序時壓力測試的重要性，并且提供一些提示使該過程更容易完成。

本文的目的是幫助有經驗的開發人員和 IT 專業人員設計和實現完整的壓力測試方案，診斷測試結果，并建議進行某些更改以糾正缺陷。本文假設讀者熟悉 Microsoft Windows NT? Server、Microsoft SQL Server?、Microsoft Internet Information Server (IIS)、Active Server Pages (ASP)、Microsoft ActiveX? 數據對象 (ADO) 和 Microsoft Component Services 環境（或者如果使用的是 Windows NT，為 Microsoft Transaction Server [MTS]）等技術。

應該強調 COM 或 DCOM 組件中業務邏輯和數據訪問過程的正確實現，包括 ADO 組件。由于性能和可靠性的原因，這些過程不應該駐留在 Active Server Page 中。如果您關心應用程序將如何在壓力下運行，則您可能已經設計了利用這些組件和組件服務環境益處的應用程序。

本文不嘗試討論由客戶端瀏覽器或帶寬限制引起的壓力問題，而是主要專注于服務器端數據訪問組件和它們與 Internet Information Server 的交互。本文也不處理因使用 Remote Data Services (RDS) 所帶來的難題。

為什么要對應用程序進行壓力測試？

在生產環境中部署應用程序之前應該總是先執行壓力測試。對支持 Web 的應用程序進行壓力測試的基本目的是達到下列目標：

• 精確測量當系統上總用戶負載增加時各用戶的具體使用境況
• 在生產環境中部署應用程序之前，確定由應用程序使用的最大硬件容量并因此確定硬件升級是否必要
• 定義應用程序用戶可接受的性能閾值，即平均頁響應時間
• 確保當系統中出現了預計的最大并發用戶負載時性能閾值能夠保持在可接受的水平上

對于要獲得成功的大多數 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 中進程外應用程序的“壓力屬性”屬性頁配置。在 Windows NT 4.0 中，選擇“在單獨的內存空間運行（獨立進程）”復選框以在進程外運行 Web 應用程序。在 Windows 2000 中，選擇“中”或“高”的“應用程序保護”設置以在進程外運行 Web 應用程序。

圖 1：Windows NT 4.0“壓力屬性”頁

圖 2：Windows 2000“壓力屬性”頁

服務器配置

配置 Internet Information Server 以鏡像生產服務器�！癐nternet 服務管理器”屬性頁為 IIS 提供各種可用的調整選項。特別重要的是確定是否啟用記錄（可以大大減慢系統速度）并且在“性能”選項卡下，選擇預期的每天點擊數。

數據服務器是可能解決與壓力相關的多數問題的地方。為了有效執行查詢，必須正確標準化數據庫設計。因此，必須用準備與應用程序一起使用的實際數據庫設計進行壓力測試，并且應確保用應用程序將生成的最大數據量填充表。此外，確保測試數據服務器配置選項（最重要的是鎖定級別和隔離級別以及使用的優化技術，例如表索引）匹配生產數據服務器的配置選項。

安全配置

應用程序的安全方案對壓力下的應用程序會有嚴重的性能影響，特別是系統包含加密技術（如 Microsoft Cryptography API）時更是如此。因此，應該配置測試系統以使用相同的安全方案，但不必使用相同的憑據。Microsoft Windows NT LAN Manager (NTLM) 傳遞身份驗證系統可能是訪問后端數據存儲區的 Intranet 應用程序的最通用安全協議。如果可能的話，應該考慮使用組件服務（或 Windows NT 中的 MTS）中的角色，以簡化安全身份驗證過程并提高效率，以及提高性能和穩定性。

用戶負載配置

首先確定預期訪問應用程序的最大用戶數，然后將該數字加倍；成功的應用程序所服務的用戶數最可能比預期的多。此外，計算多數用戶需要訪問的時間，然后確定那段時間（應該是測試應用程序的時間）內的網絡負載。該策略使您能夠測試用戶負載影響以及系統范圍的硬件配置，確保應用程序在網絡負載高峰期內按預期響應。

選擇正確的壓力工具

在實際的數據中心情況中，由于太多用戶通過 Intranet 或 Internet 連接到 Web 應用程序，Web 服務器經歷高連接水平。Web 壓力工具應能夠模擬發生高并發連接數的情形，并以充足的線程滿足最大的并發連接數，同時減小發送到 Web 服務器的數據包大小。幸運地是，有許多可用的工具被設計來模擬這些實際情況。Microsoft 的 Web 應用程序壓力工具就是這些工具中的一個，當前可從在 http://homer.rte.microsoft.com 處的 Microsoft 免費獲得它。它提供所有必要的功能和一些好的附加功能，例如廣泛的報告功能。

Web 應用程序壓力工具

Web 應用程序壓力工具通過實際模擬從 Web 應用程序請求頁的多個瀏覽器來激活測試環境，并允許通過從瀏覽器訪問想要包括到測試中的頁來記錄腳本。然后，該腳本可以在安裝有該應用程序的任何 Windows NT 或 Windows 2000 客戶端上保存和運行。因為 Web 應用程序壓力工具能夠模擬來自每個單獨工作站的多個客戶端，所以具有的可用客戶端計算機不必與生產應用程序具有的一樣多。

注意 當運行壓力測試時，注意不要增加客戶端的壓力水平，以免測試計算機在線程間的上下文切換上花費的時間比實際運行所用的時間多。若要確保線程分布于各個客戶端，請在運行基于 Web 的應用程序測試時使用幾個客戶端，從而減輕一個客戶端計算機的資源限制。

性能監視器

為了有效地對數據訪問組件進行壓力測試并正確地診斷結果，使用監視和記錄運行統計的方法極為重要。性能監視器是隨 Microsoft Windows NT 和 Microsoft Windows 2000 一起提供的工具，它是適用于在 Internet Information Server 中和數據服務器上監視和記錄這些統計的最好工具。

其他工具

除了在 Internet Information Server 上使用性能監視器外，還有必要監視數據服務器上的某些自定義計數器。大多數高性能數據服務器應用程序，例如 Microsoft SQL Server、Oracle 和 Microsoft Exchange Server，都包括自定義性能監視器計數器，可用于測定應用程序和其運行在的硬件的健康情況。

運行壓力測試

認真地擬定了測試策略后，實際運行測試是容易的。性能測試的第一個任務是使用工具，例如 Microsoft Web 應用程序壓力工具，將壓力施加到 Web 站點并測量 Web 服務器每秒能處理的最大請求數。這是定量測量。第二個任務是確定哪一個資源阻止每秒請求數的提高，例如 CPU、內存或后端相關性，這個過程更具有藝術性，而不單是一種精確測量的技術。

首先，選擇打算運行的 ASP 頁。（尋找 Web 站點的最慢頁并使用這些頁。）具體的選擇取決于哪些頁最頻繁訪問數據庫并且具有最多或最復雜的查詢。該選擇非常重要：包括比必需的更多的頁比遺漏一些關鍵代碼路徑要好。如果適當的話，還可考慮讓測試應用程序按指定的順序訪問一系列頁，并像應用程序將在真實情況中所做的那樣，將 cookie 或查詢字符串傳遞到每一頁。

注意 根據實際的應用程序，可能有必要為測試準備 ASP 頁。一些頁可能要求硬編碼通常由應用程序生成的和 Web 壓力工具不能動態生成的參數值。

當在 Internet Information Server 中運行應用程序時，應該（使用性能監視器）監視以下計數器：

• Active Server Pages：每秒請求數、被拒絕的請求數、總隊列長度和當前會話數
• Inetinfo process：專用字節數、虛擬字節數和打開句柄數
• Processor：百分比用戶時間與百分比特權時間相比

注意 如果應用程序在 Windows NT 4.0 中自己的內存空間中運行（或者在 Windows 2000 中的 Stress Properties 頁上的設置為 Application Protection: High [Isolated]），則應監視 mtx.exe（或 Windows 2000 中的 dllhost 進程）而不是監視 Inetinfo 進程。

如下圖所示，性能監視器中的 Active Server Pages 每秒請求數計數器將顯示應用程序的實際吞吐量（此例中每秒的請求數為 1.000）。該統計使您能夠診斷壓力下的 Internet Information Server 性能，并查明潛在的瓶頸。這反過來使您得以判斷應用程序以可接受的響應時間服務數量最多的用戶的能力。

圖 3：性能監視器

運行 ASP 技術的 Web 服務器從啟動時建立的池中給每頁分配一個線程；如果所有線程都已使用，后面的頁請求將被放置在隊列中。通過用性能監視器監視總的隊列長度，可以確定有多少客戶端正在等待服務器的響應。

兩個最常見的與壓力有關的非硬件數據庫問題是死鎖和鎖定并發。在數據服務器上，使用數據存儲區將提供的自定義性能監視器計數器時，應該至少監視下列內容：

• 鎖請求數
• 每秒死鎖數
• 每秒表鎖擴大數
• 用戶連接數
• 活動事務數

Web 應用程序也應配置成利用 OLE DB 資源池，該資源池由 Microsoft SQL Server 7.0 的中間層 OLE DB 提供程序自動管理。通過基于每頁創建連接對象并立即釋放它們，數據庫可以處理數千個并發用戶，而使用的開放式數據庫連接數少得多。這可保留數據庫資源并提供更大的可縮放性。應通過跟蹤數據服務器上的用戶連接數（使用性能監視器）監視此性能增強。隨著吞吐量增加，當池控制數據服務器上實際創建的連接數時，用戶連接數應保持穩定。

針對數據庫調節應用程序的過程對實現性能目標至關重要，并且必須作為因素計入開發循環。這應包括優化分配內存的大小、應用程序在磁盤驅動器和控制器上的分布以及 ActiveX 組件的計算機位置。要特別考慮盡可能消除進程間的數據封送處理，因為這是非常昂貴的操作。

運行壓力測試的時間應比應用程序在實際用戶環境中不中斷運行的預計時間長百分之五十。許多問題，尤其是內存泄漏，只有在應用程序運行時間超過預期時間后才會暴露出來。

壓力測試期間查找的內容

每個性能監視器計數器的平均值取決于特定的應用程序和硬件配置。因此，當壓力測試運行時，應該檢查每個計數器中是否有任何偏離這些平均值的異常偏差。

監視 Internet Information Server

當查找瓶頸時，在 Internet Information Server 計算機上監視的最重要方面如下：

• CPU 使用率
• 內存使用
• 吞吐量

根據設計的應用程序環境，在壓力測試期間可能還有其他要跟蹤的性能方面。下列任何可能的情況可能表明應用程序有問題，在最終發布前應修復這些問題。

CPU 使用率

CPU 使用率的減少可能表明應用程序性能的降低，可能是線程爭用問題。

當監視用戶時間和內核時間之間的 CPU 時間比時，記住作為規則，用戶時間應是 CPU 總時間的百分之八十至九十。因此，超過百分之二十的內核模式時間表明有內核級別 API 調用爭用。

為了使計算機物有所值，應該在峰值負載期間注冊超過百分之五十的處理器使用率。更低的使用率值可能提示您需要解決系統中的其他瓶頸。

內存使用

內存使用暴漲或逐步增加是另外一個問題，這個問題經常被認為是長期運行的服務器應用程序的常見問題。通常，這是內存和資源泄漏在測試階段暴露出來的地方。

吞吐量

監視 Active Server Pages 每秒請求數計數器使您得以確定應用程序開始什么時候以及是否有性能問題。該計數器在實際的應用程序中通常有所不同，但是通過認真地設置線程數和并發連接數（例如，通過 Web 應用程序壓力工具配置屏幕進行設置），將能夠模擬穩定的請求數。該計數器值的突然減少預示著麻煩。

可選測試方面

下面的是壓力測試期間可能發現值得監視的其他方面的示例：

• 總隊列長度。 通常，性能監視器中的 Total Queue Length 計數器會上下變動。因此，如果總隊列長度從不增加且您正以低處理器使用率運行，這可能表明站點運行平穩，具有的容量比該壓力負載需要的大�；蛘�，如果隊列長度正在上下變動但是處理器使用率低于百分之五十，這可能表明一些請求正被阻塞，可能需要進一步優化。
• 瀏覽器響應時間。 可以定期從瀏覽器訪問 Active Server Pages 以監視響應時間并確保壓力測試正在正確運行，并且 Web 站點仍可以正確地服務 ASP 頁。建議在壓力測試期間每天至少執行兩次此測試。
• 超時錯誤。 在瀏覽器測試期間，留心由 Internet Information Server 返回的超時錯誤；這些錯誤可能表明有太多用戶正同時訪問應用程序。

監視數據服務器

內部處理數據服務器的各種 MDAC 服務和格式化用于顯示的數據通常會消耗專用于 Web 應用程序的大多數可用服務器資源。因此，當對應用程序進行壓力測試時，如果與應用程序的數據訪問和數據操作區域有關，則必須特別考慮這些組件的性能。

數據庫用戶連接、鎖爭用和死鎖是數據服務器上要監視的主要對象。定期查看數據庫的管理控制臺中的進程信息（例如，在運行 SQL Server 的計算機上，是在 SQL 企業管理器的 Current Activity 區域中)。檢查阻塞的服務器進程 ID，它是不返回響應的數據查詢的常見原因。這是個爭用問題，并且通常要求對數據庫設計或應用程序邏輯進行重大更改。

可以用不同的方法識別死鎖。識別死鎖的最常用的方法是使用性能監視器中的 Number of Deadlocks/sec 自定義計數器。應用程序應該已經檢查死鎖問題并適當響應，因為允許數據服務器指定死鎖受害人（即，將被取消以解決死鎖的用戶或會話）會引起應用程序問題。應用程序應在遇到死鎖時檢測死鎖情況，并相應響應。遇到死鎖時一般做法是等待幾毫秒，然后再重試操作；通常，死鎖僅是對時間敏感的錯誤，當重試操作時該錯誤將會消失。

計算壓力測試結果

當完成壓力測試并且測試結果可用于檢查時，目標性能基準與測試期間收集的統計的比較將指出所需要的更改，以確保用戶將需要的吞吐量。以下是需要進行性能改正應檢查和計算的特定方面：

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

硬件

也許增加應用程序吞吐量最簡單和最經濟的解決方案是硬件升級。通常，升級硬件比付錢給開發人員團隊重寫部分應用程序要經濟高效得多。例如，只是通過將更多的 RAM 添加到服務器，您可以使應用程序的吞吐量加倍。然而，如果測試結果表明 CPU 使用率是瓶頸，則升級可能更貴，因為可能必須升級整個計算機來增加 CPU 的使用數量與速度。

其他與硬件有關的增強包括增加硬盤和控制器的速度以及添加更快或附加的網絡接口卡。

數據庫設計

當計算有關數據庫設計的問題時，請尋找作用點。分析死鎖統計，并確認已經優化了應用程序以盡可能避免死鎖。如果有必要，請考慮更改數據訪問算法以避免爭用。用不同的索引解決方案進行實驗。檢查數據服務器的查詢執行計劃以確認查詢正在使用適當的索引，等等。

ActiveX 組件

應認真分析包含對 ActiveX 數據對象類型庫的引用的 ActiveX 組件以進行可能的優化。不要使用 ADO 中允許的默認屬性。為避免意外使用默認屬性，應總是指定某些屬性，例如，Cursor Type 和 Cursor Location 屬性。

客戶端游標

如果 Web 應用程序消耗了異乎尋常的大量內存，則游標定位的不適當使用可能就是問題的原因。當使用客戶端游標 (recordset.cursorlocation = adUseClient) 時，注意客戶端實際是 Internet Information Server，而不是瀏覽器。（該規則的例外情況是當使用 Remote Data Services 時，本文不對此進行討論。）開發人員常犯的錯誤是假定客戶端游標的使用將整個記錄集移動到瀏覽器而不是運行 IIS 的計算機。因此，記住您實際正在將記錄集存儲到運行 IIS 的計算機上將使您更多地意識到所用的資源。

例如，如果應用程序要求訪問列出有效州或縣代碼的表并且該信息存儲在數據服務器中，則使用客戶端游標創建駐留在 IIS 計算機上的記錄集，然后本地訪問該代碼將更有效，這樣避免了當應用程序訪問該信息時需要另外往返于數據服務器。一定要注意利弊關系，如果內存不可用，則不要以大內存要求加重 IIS 的負載。

ASP 執行

如果包含數據訪問過程的 ASP 頁花費太長時間執行，則可能需要將數據訪問代碼從 ASP 頁移動到 ActiveX 組件，該組件一般放置在 Microsoft Transaction Server（在 Windows NT 中）的包中或 Component Services（在 Windows 2000 中）的包中，這取決于正在運行的操作系統。該編輯代碼運行效率比包含在 Active Server Page 中的解釋腳本代碼有效得多。

Internet Information Server 負載

監視正使用 Internet Information Server 的應用程序數量和類型�？赡苄枰�添加附加的服務器，將應用程序移動到另一服務器，或者考慮實現 Windows Load Balancing Service。

成功運行壓力測試的提示

• 要：
  • 將所有業務邏輯放在 ActiveX 組件中，并使用 ASP 頁作為將所有事物連接在一起的膠貼物。將可再次使用的代碼封裝入庫。
  • 使用 MTS（Windows NT 用戶）。該出色的工具提供附加的線程和資源池，以用于服務器端 COM 對象并且更容易管理對象。此外， MTS 提供業務功能。
  • 使用資源/連接池。默認情況下，該 MDAC 功能是啟用的，但是應該對其監視以確保它正確工作。
  • 調節數據存儲區。在可適用的地方使用存儲過程。
  • 為了最小化數據訪問操作，為輸入、輸出和轉換數據使用緩存。
  • 只要有機會就使用進程內應用程序和 ActiveX 組件。
  • 確保生產環境中調試是禁用的。調試應用程序會強制線程相似性。
  • 在 Intranet 環境中，只要可行，將工作卸載給客戶端瀏覽器。
  • 升級到 Windows 2000。當對應用程序進行壓力測試時，包括在該新版本中的性能和可縮放性增強即刻顯現。
  • 如果這時無法升級到 Windows 2000，至少應該升級到 Microsoft Visual Basic? Scripting Edition (VBScript) 5.0；在該新版本中性能和功能已大大提高。
  • 考慮使用 Microsoft Message Queue Server (MSMQ)。恰當使用異步消息處理將大大增加可感知的用戶響應時間。
• 不要：
  • 使用 Active Server Page 中的應用程序或會話級別對象。
  • 將數據訪問代碼放在 Active Server Page 中。使用腳本代碼與 ActiveX 組件中的數據訪問函數和業務規則進行通訊。
  • 使用 HTTPS/安全套接字層，除非絕對必要。實現該身份驗證協議非常昂貴。
  • 使用應用程序狀態或會話狀態（在不必要時）。

結束摘要

Internet 使您的應用程序可以比傳統的客戶端－服務器應用程序面向更多的潛在用戶。隨著越來越多的組織將 Web 作為他們業務策略的策略部分，他們需要確保他們選擇的技術可以處理他們苛求的需要。除了容易使用的工具，這些組織還需要基礎結構來滿足他們用戶負載要求。因此，壓力測試是測試體系的基礎部分這個理念比以前更重要，特別是當將 MDAC 合并到應用程序中時。

注意 在壓力情況下成功運行的基本要求是在開發周期中采取最佳慣例方法。這就意味著為負載條件下的性能測試和調整應用程序以達到性能目標的時間調度必須考慮到開發過程中。

負載下的壓力測試和反復調節應用程序的好處是簡單明了：

• 獲得需要的信息以確保應用程序取得最好的吞吐量結果。
• 可以精確地評定應用程序的可縮放性特征，以便可以調整應用程序達到指定的性能目標。
• 可以盡早發現降低性能和吞吐量的設計問題，并且在將應用程序部署到生產之前可以進行調整。
• 應用程序將因為其高性能可信賴性而在客戶與業務伙伴中樹立起聲譽。