簡介
在開發和部署 Microsoft Windows DNA 應用程序時，對應用程序進行強度測試這一步驟常被忽略，而它卻能保證，在生產環境中有大量授權用戶訪問應用程序時，它能正常執行。本文著重介紹，在利用“Microsoft 數據訪問組件 (MDAC)”開發應用程序時，進行強度測試的重要性，另外還提供輕松完成該過程的一些技巧。
本文旨在幫助有經驗的開發人員和 IT 專業人士，設計和實現一個完整的強度測試方案，診斷測試結果，并針對方案的缺陷提出改進意見。本文假定讀者已熟悉 Microsoft Windows NT Server、Microsoft SQL Server、Microsoft Internet 信息服務器 (IIS)、Active Server Pages (ASP)、Microsoft ActiveX Data Objects (ADO) 等技術，以及“Microsoft 組件服務”環境（若使用 Windows NT，則為 Microsoft Transaction Server [MTS]）。
在 COM 或 DCOM 組件（包括 ADO 組件）中，應強調業務邏輯和數據訪問過程的正確實現。為性能和可靠性起見，這些過程不應駐留在 Active Server Pages 中。如果您關心自己的應用程序在強度下運作的情況，那么您很可能已將應用程序設計為利用這些組件，并利用“組件服務”環境的有利因素。
本文不打算討論客戶端瀏覽器或帶寬限制導致的強度問題，而重點關注服務器端的數據訪問組件，及其與“Internet 信息服務器”的交互作用。本文也不涉及因使用“遠程數據服務 (RDS)”而產生的復雜問題。
為什么對我的應用程序進行強度測試？
在生產環境下部署應用程序之前，都應進行強度測試。對啟用 Web 的應用程序進行強度測試，其根本目的在于實現以下內容：
- 精確度量系統增加了整體用戶負載之后的單個用戶的體驗
- 確定應用程序使用的硬件的最大容量，并以此確定，在生產環境中部署該應用程序之前，是否有必要將硬件升級
- 根據應用程序用戶的平均頁面響應時間，確定能接受的性能閾值
- 確保在系統承受估計的最高并發用戶負載時，其性能閾值仍保持在可接受的水平
就大多數 Web 應用程序而言，用戶的體會是，只要應用程序成功了，其他都不在話下。然而，有許多很好的理由說明，您的應用程序需要通過強度測試，理由如下：
- 在開發過程中狀態良好的應用程序，在強度測試環境中會表現得很差。例如，當多個應用程序同時使用“Internet 信息服務器”或 SQL Server 機器時，若再向其中增加新的應用程序，而您又未將該應用程序設計為在該情形下正常運作的話，就會干擾甚至中斷已有的應用程序。
- 您的客戶在最初幾次使用您的應用程序時，會形成其對應用程序的最重要的印象。如果因為強度問題使客戶的這一印象不佳，則很難扭轉這個印象，即使您事后已解決了那些問題。從另一方面來講，如果您的應用程序在部署前經過了充分的強度測試，那么作為一個創建了既好又快且能按客戶需要運行的應用程序的開發人員，您自然能在客戶心中建立起聲譽。
- 負責部署和維護此應用程序的 IT 小組，甚至比您的用戶更感激您做了強度測試。他們站在第一線，將最先聽到用戶的意見和看法。如果您能提前確切地想到可伸縮性問題，而這個問題會影響到 IT 小組，那么這個組的成員會在您需要他們的技術時，積極主動地幫助您。
- 針對客戶滿意的考慮中還包括潛在的合作伙伴。如果他們決定將您的應用程序納為其更大的應用程序軟件包的一部分，就會使您的應用程序增添更大的成功。
進行強度測試前的準備工作
要確定最佳情況下服務器分析值（亦稱基線），應首先在控制環境中測試引導系統的配置。接下來應在模擬的生產環境下測試，以確定生產環境的配置對引導系統結果的影響情況。
在開發周期的強度測試準備階段，應著重考慮以下幾個方面：
- 硬件和軟件配置
- 服務器配置
- 安全配置
- 用戶負載配置
- 選擇正確的強度工具
硬件和軟件配置
引導系統應盡可能地鏡像生產系統。CPU、RAM 和網絡帶寬的硬件配置，是強度測試中需針對的最重要的領域。要盡最大努力復制軟件配置，如適當的 Microsoft Windows 版本和服務包、MDAC 版本、“Internet 信息服務器”配置，以及在實際的生產系統中同一機器上運行的所有其他應用程序。安裝和注冊中間層業務規則和數據訪問 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 信息服務器”配置為鏡像生產服務器。Internet 服務管理器屬性頁為 IIS 提供各種不同的調節選項。其中尤為重要的是，確定是否啟用日志（它可顯著地減慢系統的速度），以及在性能選項卡下選擇期望每日訪問的數量。
在數據服務器中，大多數與強度相關的問題都是有可能解決的。為了更有效地執行查詢，嚴格意義的數據庫設計的正�；瘎菰诒匦�。因此，對您的應用程序即將涉及的實際數據庫進行強度測試，也是勢在必行的，而且您還應確保那些表植入了您的應用程序所能產生的最大量的數據。另外，要保證您的測試數據服務器的配置選項（最重要的是使用的鎖定和單獨級別以及優化技術 — 例如，表索引）與生產數據服務器的配置選項相一致。
安全配置
在您的應用程序的安全方案中，會有在強度下影響到應用程序的嚴重性能問題，尤其是在系統包含加密技術（如 Microsoft Cryptography API）的情況下。因此，您應將測試系統配置為使用同一安全方案，但不必使用同一憑證。Microsoft Windows NT LAN Manager (NTLM) 通過驗證系統，也許是訪問后端數據存儲的 intranet 應用程序的最通用的安全協議。如果可能，您應當考慮使用“組件服務”內部的角色（若在 Windows NT，則為 MTS），來簡化和優化安全驗證進程，從而提高性能和穩定性。
用戶負載配置
首先確定預期訪問您的應用程序的最大用戶量，再把這個數加倍；成功的應用程序非�？赡転檫h遠多于預計數量的用戶而使用。另外，再計算每天大多數用戶需要訪問的時間，然后確定那個時間段的網上負載。這個策略使您能測試用戶負載的影響，以及系統范圍內的硬件配置，以保證應用程序在網絡高峰期能夠照常響應。
選擇正確的強度工具
在實際的數據中心環境下，Web 服務器總是處于高的連接水平，因為許許多多客戶，通過公司 intranet 或者 Internet 連著 Web 應用程序。Web 強度工具應當有能力模擬大量帶有足夠線程的并發連接，在縮小發送至 Web 服務器的程序包大小的同時，最大限度地增加并發連接。很高興的是，已經有了不少這樣的工具，它們可以精確地模擬這些情況。其中一例，就是 Microsoft 的 Web“應用程序強度工具”，這是當前可從 Microsoft（站點 http://webtool.rte.microsoft.com/（英文））免費獲得的工具。它提供了所有必需的能力，以及一些最好的附加功能，例如，擴展的報告功能。
Web 應用程序增加強度工具
Web 應用程序增加強度工具，通過實際模擬多個請求 Web 應用程序的頁面的瀏覽器，來激活測試環境，并且允許從您的瀏覽器訪問想要包括在協議中的頁面，從而能夠記錄腳本。于是，該腳本能夠在任何安裝了此應用程序的 Windows NT 或 Windows 2000 客戶機上保存和運行。因為 Web 應用程序增加強度工具能夠模擬每個獨立工作站上的多個客戶機，所以沒必要配備和您的生產應用程序所配備的一樣多的客戶機。
注意 在運行增加強度工具時，請小心不要增加客戶機上的強度級別，免得您的測試機器在線程間的上下文切換上所花費的時間，比做實際工作花的時間還多。要保證線程確實分布在多個客戶機上，請在對基于 Web 的應用程序進行測試時使用多個客戶機，從而減輕單一的客戶機對資源的限制。
性能監視器
為了有效地對數據訪問組件進行強度測試并正確診斷結果，監視和記錄運作統計數據的方法是極其重要的�！靶阅鼙O視器”是隨 Microsoft Windows NT 和 Microsoft Windows 2000 一起提供的工具；無論是在“Internet 信息服務器”上，還是在您的數據服務器上，“性能監視器”都是監視和記錄這些統計數據的最好工具。
其他工具
除了利用“Internet 信息服務器”上的“性能監視器”之外，還要監視數據服務器上的一些自定義的計數器。性能最好的數據服務器應用程序（如，Microsoft SQL Server、Oracle 和 Microsoft Exchange Server）中，都含有自定義的性能監視器計數器，用它們可以測量應用程序的健壯性和運行此應用程序所用的硬件的健壯性。
進行強度測試
當您仔細策劃好測試策略之后，具體的測試工作便非常簡單了。性能測試的第一個任務即使用工具，如 Microsoft Web 應用程序增加強度工具，以對 Web 站點增加強度，測量每秒鐘 Web 站點能夠處理的最大請求數。這是定量測試。第二個任務是，確定阻礙了每秒請求數進一步增長的資源，是 CPU、內存，還是后端相關領域；這個過程與其說是精確的測量技術，不如說是一種藝術。
首先，運行計劃要運行的 ASP 頁。（尋找 Web 站點中運行得最慢的頁，并使用它們。）具體的選擇，取決于哪些頁面訪問數據庫最頻繁，而且使用最大和最復雜的查詢。這樣選擇非常重要：最好所含頁面比需要的再多些，以免漏掉某些重要的代碼路徑。同時，盡可能考慮讓您的測試應用程序以指定的順序訪問一系列頁面，并將 cookie 或者查詢串傳送到每個頁面，就像此應用程序在真實世界中所做的那樣。
注意 根據實際的應用程序，可能需要準備測試用的 ASP 頁。部分頁可能要求您硬編碼參數值，這些值通常由應用程序生成，而 Web 增加強度工具是無法動態生成的。
在“Internet 信息服務器”內部運行您的應用程序時，應當監視（用“性能監視器”）下列計數器：
- Active Server Pages：每秒請求數、被拒絕的請求、總的查詢長度和當前會話數
- Inetinfo 進程：私有字節、虛擬字節和打開的句柄數
- 處理器：用戶時間百分比與特權時間百分比
注意 在 Windows NT 4.0（在 Windows 2000 中則使用強度屬性頁中的應用程序保護：高（單獨） 設置）中，如果您的應用程序運行在它自己的內存空間，則應監視 mtx.exe（在 Windows 2000 則監視 dllhost 進程），而不是監視 Inetinfo 進程。
如下圖所示，“性能監視器”中 Active Server Pages 每秒請求數計數器將顯示您的應用程序的實際吞吐量（在此例中為 1.000 個請求/秒）。這個統計數據使您能夠診斷“Internet 信息服務器”在強度情況下的性能，并指出了潛在的瓶頸。也就是使您能夠調整應用程序的能力，使它在用戶數量達到最多時還能提供可接受的響應時間。
圖 3. 性能監視器
運行 ASP 技術的 Web 服務器，從啟動時確定的緩存中，給每個頁面請求分配一個線程；如果所有的線程都用了，后面的頁面請求則放入隊列中。利用“性能監視器”監視總的查詢長度，即可確定有多少客戶機正在等待服務器的響應。
有兩個最常見的非硬件強度相關的數據庫問題，即死鎖和鎖定并發。在數據服務器中，利用數據存儲可提供的自定義“性能監視器”計數器，起碼可監視以下內容：
- 鎖定請求
- 每秒死鎖
- 每秒表鎖定擴大
- 用戶連接
- 活動的事務
您的 Web 應用程序還應當配置成利用緩存的 OLE DB 資源，在 Microsoft SQL Server 7.0 中，該資源是由中間層 OLE DB 提供者自動管理的。如果在每頁的基礎上創建連接對象，并立即釋放它們，數據庫便能用很少的打開的數據庫連接，來處理數以千計的并發用戶。這樣做，節省了數據庫資源，并能提供極大的可伸縮性。在數據服務器上，這樣的性能提高，可以通過跟蹤用戶連接數（使用“性能監視器”）來監視。隨著吞吐量的增加，用戶連接數應保持穩定，因為緩存控制著數據服務器上自動創建的連接數。
針對數據庫而調整應用程序，對于實現性能目標是十分重要的，而且應歸屬于開發階段。這種調整包括優化分配內存的大小，優化應用程序在磁盤驅動器和控制器上的分布，以及 ActiveX 組件的機器位置。應十分重視消除進程間的數據匯集，因為這種數據匯集是一種極其昂貴的操作。
連續進行強度測試的時間周期，應比此應用程序在實際的用戶環境中所希望的運行時間長 50％。在應用程序尚未運行到延長的時間周期之前，要對許多問題（特別是內存泄漏問題）下結論為時尚早。
強度測試期間的針對內容
每個“性能監視器”計數器的平均值，取決于您的特定應用程序和硬件配置。因此，在進行強度測試時，應檢查每一個計數器，以發現與這些平均值的反常差異。
監視“Internet 信息服務器”
尋找瓶頸時，監視器在“Internet 信息服務器” 機器上的最重要部分如下：
- CPU 利用率
- 內存的使用
- 吞吐量
因具體的應用程序環境而異，還可以選擇在進行強度測試時需要跟蹤的其他一些性能方面。下面可能方案中的任何一個，都可能發現應用程序中的問題。在最終發布之前，這些問題都是應當解決的。
CPU 利用率
CPU 利用率的下降，可以表示應用程序性能的下降，可能是線程的爭用出了問題。
在監視用戶態和核心態所占的 CPU 時間時，要記住，一般情況下用戶態占用的時間，應當是總的 CPU 時間的 80 到 90％。因此，如果核心態占用的 CPU 時間超過了 20％，則說明存在核心級 API 調用的爭用。
若要充分利用您的機器，請將高峰期間的處理器利用率注冊在 50％ 以上。較低的利用率說明在系統中還有需要解決的其他瓶頸。
內存的使用
對長時間運行的服務器應用程序來說，內存使用的突跳或漸增，是經常標識為常見問題的另一個領域。通常，這說明在測試階段中還存在內存和資源的泄漏。
吞吐量
監視 Active Server Pages 每秒請求數計數器，能使您識別應用程序何時或是否開始出現性能問題。在實用的應用程序中，該計數器通�？偸窃谧兓�；但是，如果細心地設置線程數和并發連接數（例如，從“Web 應用程序強度工具”配置屏幕），就能夠模擬穩定的請求數。該計數器的突降意味著出現了故障。
可以選擇的測試方面
下面舉例說明在強度測試期間極為值得注意的其他方面：
- 總查詢長度。 通常，“性能監視器”中的總查詢長度計數器總是在上下變化。因此，如果總查詢長度從不增加，而您正在低的處理器利用率下運行，這可能說明您有一個平穩運行的站點，其能力已經超過了強度負載的需要�；蛘�，若是您的查詢長度正在上下變化，但是您的處理器運行在 50％ 以下，這可能說明您的一些請求已被阻塞，并要求進一步優化。
- 瀏覽器響應時間。 您可以定期從瀏覽器訪問您的 Active Server Pages，以監視響應時間，并保證這次強度測試能順利進行，而且 Web 站點仍能正常服務于 ASP 頁面。我們建議，在強度測試期間，這樣的測試每天至少執行兩次。
- 超時錯誤。 瀏覽器測試期間由“Internet 信息服務器”返回的超時錯誤。這些錯誤可能表示當前正有太多的用戶同時訪問此應用程序。
監視數據服務器
供 Web 應用程序使用的服務器資源，多半消耗在用數據服務器內部處理各種各樣的 MDAC 服務以及格式化要顯示的數據上面。因此，在對應用程序進行強度測試時，當這些組件與此應用程序的數據訪問和數據處理方面有關時，對它們的性能予以特別的考慮已是勢在必行。
數據庫用戶連接、鎖定爭用和死鎖，是監視數據服務器的主要選項。在您的數據庫的管理控制臺（例如，在運行 SQL Server 的機器上，在“SQL 企業管理器”的當前活動區）上定期查看進程信息。檢查阻塞的服務器進程 ID，不返回響應的數據查詢的常見原因。這是個爭用問題，通常要求數據庫設計或應用程序邏輯做重大更改。
識別死鎖的方法很多。識別死鎖的最常見方法，是用“性能監視器”中的死鎖數/每秒自定義計數器。您的應用程序應當已經檢查過死鎖問題，并得到了適當的響應，因為允許數據服務器指定死鎖的受害者（即，為了解決死鎖，可以取消該用戶或會話）可能會使您的應用程序出錯。當遇見死鎖并因此而作出響應時，此應用程序應當檢測死鎖的條件。對死鎖的常見響應是等待幾個毫秒，然后重試這次操作；通常，死鎖僅為簡單的時間敏感錯誤，在重試操作時便會消失。
評估強度測試的結果
在完成強度測試并可檢查測試結果時，目標性能基準與測試過程中收集到的統計數據之間的對比將表明所需要的更改，以保證用戶要求的吞吐量。下面是為修正性能應查看和評估的幾個方面：
- 硬件
- 數據庫設計
- ActiveX 組件
- 客戶機游標
- ASP 執行
- IIS 負載
硬件
增加應用程序吞吐量的最容易最省錢的解決方案是硬件升級。一般來說，與組織一支開發隊伍來改寫應用程序的多個部分相比，更新硬件要合算得多。例如，簡單地添加服務器的 RAM，就可以使應用程序的吞吐量翻番。然而，要是測試結果說明您的 CPU 利用率是瓶頸，則升級可能更昂貴，因為要想增加 CPU 的數量和速度，恐怕整臺機器都要升級。
其他硬件方面的增強包括提高硬盤驅動器和控制器的速度，添加更快的或附加的網卡。
數據庫設計
在評估數據庫設計的相關問題時，請找出熱點。分析死鎖的統計數據，并確認您的應用程序在避免死鎖的問題上已經盡量優化了。如果一定要避免爭用的話，可以考慮更改數據訪問的算法。試驗不同的索引方案。檢查數據服務器的查詢執行計劃，以保證您的查詢使用正確的索引，如此等等。
ActiveX 組件
為了盡量優化引用了“ActiveX 數據對象”類型庫的 ActiveX 組件，應對它仔細分析。不要使用 ADO 中允許的默認屬性。為了避免偶然使用默認屬性，請始終指定屬性，例如，游標類型和游標位置等等。
客戶機游標
如果您的 Web 應用程序要消耗海量內存，那么游標位置的不恰當使用可能是問題的原因。當使用客戶機游標 (recordset.cursorlocation = adUseClient) 時，要記住，這客戶機實際上是“Internet 信息服務器”，不是瀏覽器。（本規則的例外是當使用“遠程數據服務”時，它的內容已不在本文討論之列。）常見的開發人員錯誤是以為使用客戶機游標將整個記錄集移動到瀏覽器，而不是移動到運行 IIS 的機器。因此，記住您實際上正在將記錄集存儲到運行 IIS 的機器上，將使您更加清楚所使用的資源。
例如，如果您的應用程序要求訪問含有有效州代碼和國家/地區代碼的表，而這個信息存儲在數據服務器內，那么使用客戶機游標創建常駐在 IIS 機器上的記錄集，然后在本地訪問這些代碼，將是非常高效的，每當應用程序訪問這些信息時，不必再在與數據服務器之間來回傳輸。您一定要懂得如何平衡，如果內存不夠則不要用大的內存需求使 IIS 過載。
ASP 執行
如果包含數據訪問過程的 ASP 頁面的執行時間太長，可能需要將數據訪問代碼從 ASP 頁面移動到 ActiveX 組件，因使用的操作系統而異，最好將它們放入“Microsoft 事務服務器”（在 Windows NT）內部的軟件包內，或者“組件服務”（在 Windows 2000）內部的軟件包內。這樣編譯的代碼，比 Active Server Pages 內部的解釋腳本碼，其運行效率要高得多。
“Internet 信息服務器”負載
監視正在使用“Internet 信息服務器”的應用程序的數量和類型。您可能需要添加附加的服務器，將應用程序移動到另一個服務器上，或考慮實現“Windows 負載平衡服務”。
成功地進行強度測試的技巧
- 應該做的事情：
- 將所有業務邏輯放入 ActiveX 組件，并用 ASP 頁作為粘結劑將所有內容捆綁在一起。將可重用的代碼封裝到庫中。
- 使用 MTS（Windows NT 用戶）。這是一個大的工具，它為服務器端的 COM 對象提供附加的線程和資源緩存，并很容易管理這些對象。另外，MTS 還提供了處理事務的能力。
- 使用資源/連接緩存。這是默認情況下啟用的 MDAC 特性，但應當監視它，以保證它工作正常。
- 調整數據存儲。盡可能使用存儲過程。
- 若要將數據訪問操作減至最少，請對要輸入、輸出和轉換的數據采用緩存。
- 盡可能采用進程內的應用程序和 ActiveX 組件。
- 在生產環境中，一定要禁用調試程序。調試程序時會強加線程關系。
- 在 intranet 環境中，盡可能將工作交給客戶機瀏覽器去做。
- 升級到 Windows 2000。在這次新的發布中增強的性能和可伸縮性，在對應用程序進行強度測試時可立竿見影。
- 如果這時不能升級到 Windows 2000，至少升級到 Microsoft Visual Basic Scripting Edition (VBScript) 5.0 是個好主意；在這個新版本中，性能和功能將有明顯改善。
- 考慮使用“Microsoft 消息隊列服務器 (MSMQ)”。正確使用異步通知，將增強對大量用戶響應次數的感知。
- 不應該做的事情：
- 在 Active Server Pages 中使用應用程序或會話級對象。
- 將數據訪問代碼放入 Active Server Pages。使用腳本代碼與 ActiveX 組件內部的數據訪問函數和業務規則通信。
- 除了絕對需要的地方，在其他地方也使用“HTTPS/安全套接字層”。實現這個驗證協議的成本太高。
- 在不必要時也使用應用程序狀態或會話狀態。
總結
Internet 向比傳統的客戶機－服務器應用程序多得多的潛在用戶開放了您的應用程序。隨著越來越多的組織將 Web 視作他們經營策略的一部分，他們需要保證所選用的技術能夠滿足日益苛刻的要求。除了容易使用的工具之外，這些組織還要求基礎的架構能滿足他們用戶負載的需求。因此，將強度測試作為測試計劃的基本部分要高于一切，尤其是當您的應用程序合并了 MDAC 之后。
注意 在強度測試條件下，應用程序能夠正常運轉的最起碼條件，是在開發過程中采取最好的、從實際中來的方法。這意味著必須在開發階段留出這兩步的時間：一是加載測試的時間，二是為實現性能目標而調試程序的時間。
在加載條件下進行強度測試和反復調試程序，有下列顯而易見的好處：
- 可以獲得為保證應用程序有較高吞吐量所需的信息。
- 您可以準確地獲得應用程序的可伸縮性特征，因此可以有的放矢地調整應用程序。
- 很容易發現使性能和吞吐量下降的設計問題，能在將應用程序部署到生產環境之前進行調整。
- 在您的客戶和商業伙伴中間，您的應用程序將獲得高性能的良好聲譽。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
