介紹
為什么要對應用程序進(jìn)行壓力測試？
準備運行壓力測試
運行壓力測試
計算壓力測試結果
成功運行壓力測試的提示
結束摘要
Microsoft? Windows? DNA 應用程序的開(kāi)發(fā)和部署中經(jīng)常被忽略的步驟是對應用程序進(jìn)行壓力測試，確保當生產(chǎn)環(huán)境中最大數量的授權用戶(hù)訪(fǎng)問(wèn)該應用程序時(shí)，它將按預期執行。本文強調當涉 及使用 Microsoft Data Access Components (MDAC) 開(kāi)發(fā)應用程序時(shí)壓力測試的重要性，并且提供一些提示使該過(guò)程更容易完成。
本文的目的是幫助有經(jīng)驗的開(kāi)發(fā)人員和 IT 專(zhuān)業(yè)人員設計和實(shí)現完整的壓力測試方案，診斷測試結果，并建議進(jìn)行某些更改以糾正缺陷。本文假設讀者熟悉 Microsoft Windows NT? Server、Microsoft SQL Server?、Microsoft Internet Information Server (IIS)、Active Server Pages (ASP)、Microsoft ActiveX? 數據對象 (ADO) 和 Microsoft Component Services 環(huán)境（或者如果使用的是 Windows NT，為 Microsoft Transaction Server [MTS]）等技術(shù)。
應該強調 COM 或 DCOM 組件中業(yè)務(wù)邏輯和數據訪(fǎng)問(wèn)過(guò)程的正確實(shí)現，包括 ADO 組件。由于性能和可靠性的原因，這些過(guò)程不應該駐留在 Active Server Page 中。如果您關(guān)心應用程序將如何在壓力下運行，則您可能已經(jīng)設計了利用這些組件和組件服務(wù)環(huán)境益處的應用程序。
本文不嘗試討論由客戶(hù)端瀏覽器或帶寬限制引起的壓力問(wèn)題，而是主要專(zhuān)注于服務(wù)器端數據訪(fǎng)問(wèn)組件和它們與 Internet Information Server 的交互。本文也不處理因使用 Remote Data Services (RDS) 所帶來(lái)的難題。
在生產(chǎn)環(huán)境中部署應用程序之前應該總是先執行壓力測試。對支持 Web 的應用程序進(jìn)行壓力測試的基本目的是達到下列目標：
對于要獲得成功的大多數 Web 應用程序，用戶(hù)體驗最為關(guān)鍵。然而，使應用程序經(jīng)過(guò)壓力測試過(guò)程有許多充足的理由，包括：
要確定最佳情況下的服務(wù)器分析值（也稱(chēng)為基準），應首先在受控環(huán)境中測試試驗系統配置。其次，應該在模擬生產(chǎn)環(huán)境中測試以確定生產(chǎn)環(huán)境配置如何影響試驗系統的結果。
在準備開(kāi)發(fā)循環(huán)的壓力測試階段時(shí)，需要注意以下方面：
試驗系統應盡可能鏡像生產(chǎn)系統。CPU、RAM 和網(wǎng)絡(luò )帶寬的硬件配置是將在壓力測試期間被檢測的最重要方面。應努力復制軟件配置，例如適當的 Microsoft Windows 版本和 Service Pack、MDAC 版本、Internet Information Server 配置和將在實(shí)際生產(chǎn)系統中的相同機器上運行的任何其他應用程序。安裝和注冊中間層業(yè)務(wù)規則和數據訪(fǎng)問(wèn) COM 組件，并按應用程序設計要求對它們進(jìn)行配置。
務(wù)必將測試 Web 站點(diǎn)配置成能夠在進(jìn)程內或進(jìn)程外運行，具體配置成什么樣以最終配置的要求為準。選擇該選項將確定 Web 應用程序是在 IIS 所在的同一地址空間中運行，還是在它自己的獨立地址空間中運行。該配置對于要執行的壓力測試有主要影響。下圖顯示了 Microsoft Windows NT 4.0 和 Microsoft Windows 2000 中進(jìn)程外應用程序的“壓力屬性”屬性頁(yè)配置。在 Windows NT 4.0 中，選擇“在單獨的內存空間運行（獨立進(jìn)程）”復選框以在進(jìn)程外運行 Web 應用程序。在 Windows 2000 中，選擇“中”或“高”的“應用程序保護”設置以在進(jìn)程外運行 Web 應用程序。
圖 1：Windows NT 4.0“壓力屬性”頁(yè)
圖 2：Windows 2000“壓力屬性”頁(yè)
配置 Internet Information Server 以鏡像生產(chǎn)服務(wù)器。“Internet 服務(wù)管理器”屬性頁(yè)為 IIS 提供各種可用的調整選項。特別重要的是確定是否啟用記錄（可以大大減慢系統速度）并且在“性能”選項卡下，選擇預期的每天點(diǎn)擊數。
數據服務(wù)器是可能解決與壓力相關(guān)的多數問(wèn)題的地方。為了有效執行查詢(xún)，必須正確標準化數據庫設計。因此，必須用準備與應用程序一起使用的實(shí)際數據庫 設計進(jìn)行壓力測試，并且應確保用應用程序將生成的最大數據量填充表。此外，確保測試數據服務(wù)器配置選項（最重要的是鎖定級別和隔離級別以及使用的優(yōu)化技 術(shù)，例如表索引）匹配生產(chǎn)數據服務(wù)器的配置選項。
應用程序的安全方案對壓力下的應用程序會(huì )有嚴重的性能影響，特別是系統包含加密技術(shù)（如 Microsoft Cryptography API）時(shí)更是如此。因此，應該配置測試系統以使用相同的安全方案，但不必使用相同的憑據。Microsoft Windows NT LAN Manager (NTLM) 傳遞身份驗證系統可能是訪(fǎng)問(wèn)后端數據存儲區的 Intranet 應用程序的最通用安全協(xié)議。如果可能的話(huà)，應該考慮使用組件服務(wù)（或 Windows NT 中的 MTS）中的角色，以簡(jiǎn)化安全身份驗證過(guò)程并提高效率，以及提高性能和穩定性。
首先確定預期訪(fǎng)問(wèn)應用程序的最大用戶(hù)數，然后將該數字加倍；成功的應用程序所服務(wù)的用戶(hù)數最可能比預期的多。此外，計算多數用戶(hù)需要訪(fǎng)問(wèn)的時(shí)間，然 后確定那段時(shí)間（應該是測試應用程序的時(shí)間）內的網(wǎng)絡(luò )負載。該策略使您能夠測試用戶(hù)負載影響以及系統范圍的硬件配置，確保應用程序在網(wǎng)絡(luò )負載高峰期內按預 期響應。
在實(shí)際的數據中心情況中，由于太多用戶(hù)通過(guò) Intranet 或 Internet 連接到 Web 應用程序，Web 服務(wù)器經(jīng)歷高連接水平。Web 壓力工具應能夠模擬發(fā)生高并發(fā)連接數的情形，并以充足的線(xiàn)程滿(mǎn)足最大的并發(fā)連接數，同時(shí)減小發(fā)送到 Web 服務(wù)器的數據包大小。幸運地是，有許多可用的工具被設計來(lái)模擬這些實(shí)際情況。Microsoft 的 Web 應用程序壓力工具就是這些工具中的一個(gè)，當前可從在 http://homer.rte.microsoft.com 處的 Microsoft 免費獲得它。它提供所有必要的功能和一些好的附加功能，例如廣泛的報告功能。
Web 應用程序壓力工具通過(guò)實(shí)際模擬從 Web 應用程序請求頁(yè)的多個(gè)瀏覽器來(lái)激活測試環(huán)境，并允許通過(guò)從瀏覽器訪(fǎng)問(wèn)想要包括到測試中的頁(yè)來(lái)記錄腳本。然后，該腳本可以在安裝有該應用程序的任何 Windows NT 或 Windows 2000 客戶(hù)端上保存和運行。因為 Web 應用程序壓力工具能夠模擬來(lái)自每個(gè)單獨工作站的多個(gè)客戶(hù)端，所以具有的可用客戶(hù)端計算機不必與生產(chǎn)應用程序具有的一樣多。
注意當運行壓力測試時(shí)，注意不要增加客戶(hù)端的壓力水平，以免測試計算機在線(xiàn)程間的上下文切換上花費的時(shí)間比實(shí)際運行所用的時(shí)間多。若要確保線(xiàn)程分布于各個(gè)客戶(hù)端，請在運行基于Web的應用程序測試時(shí)使用幾個(gè)客戶(hù)端，從而減輕一個(gè)客戶(hù)端計算機的資源限制。
為了有效地對數據訪(fǎng)問(wèn)組件進(jìn)行壓力測試并正確地診斷結果，使用監視和記錄運行統計的方法極為重要。性能監視器是隨 Microsoft Windows NT 和 Microsoft Windows 2000 一起提供的工具，它是適用于在 Internet Information Server 中和數據服務(wù)器上監視和記錄這些統計的最好工具。
除了在 Internet Information Server 上使用性能監視器外，還有必要監視數據服務(wù)器上的某些自定義計數器。大多數高性能數據服務(wù)器應用程序，例如 Microsoft SQL Server、Oracle 和 Microsoft Exchange Server，都包括自定義性能監視器計數器，可用于測定應用程序和其運行在的硬件的健康情況。
認真地擬定了測試策略后，實(shí)際運行測試是容易的。性能測試的第一個(gè)任務(wù)是使用工具，例如 Microsoft Web 應用程序壓力工具，將壓力施加到 Web 站點(diǎn)并測量 Web 服務(wù)器每秒能處理的最大請求數。這是定量測量。第二個(gè)任務(wù)是確定哪一個(gè)資源阻止每秒請求數的提高，例如 CPU、內存或后端相關(guān)性，這個(gè)過(guò)程更具有藝術(shù)性，而不單是一種精確測量的技術(shù)。
首先，選擇打算運行的 ASP 頁(yè)。（尋找 Web 站點(diǎn)的最慢頁(yè)并使用這些頁(yè)。）具體的選擇取決于哪些頁(yè)最頻繁訪(fǎng)問(wèn)數據庫并且具有最多或最復雜的查詢(xún)。該選擇非常重要：包括比必需的更多的頁(yè)比遺漏一些關(guān)鍵 代碼路徑要好。如果適當的話(huà)，還可考慮讓測試應用程序按指定的順序訪(fǎng)問(wèn)一系列頁(yè)，并像應用程序將在真實(shí)情況中所做的那樣，將 cookie 或查詢(xún)字符串傳遞到每一頁(yè)。
注意根據實(shí)際的應用程序，可能有必要為測試準備ASP頁(yè)。一些頁(yè)可能要求硬編碼通常由應用程序生成的和Web壓力工具不能動(dòng)態(tài)生成的參數值。
當在 Internet Information Server 中運行應用程序時(shí)，應該（使用性能監視器）監視以下計數器：
注意如果應用程序在Windows NT 4.0中自己的內存空間中運行（或者在Windows 2000中的Stress Properties頁(yè)上的設置為Application Protection: High [Isolated]），則應監視mtx.exe（或Windows 2000中的dllhost進(jìn)程）而不是監視Inetinfo進(jìn)程。
如下圖所示，性能監視器中的 Active Server Pages 每秒請求數計數器將顯示應用程序的實(shí)際吞吐量（此例中每秒的請求數為 1.000）。該統計使您能夠診斷壓力下的 Internet Information Server 性能，并查明潛在的瓶頸。這反過(guò)來(lái)使您得以判斷應用程序以可接受的響應時(shí)間服務(wù)數量最多的用戶(hù)的能力。
圖 3：性能監視器
運行 ASP 技術(shù)的 Web 服務(wù)器從啟動(dòng)時(shí)建立的池中給每頁(yè)分配一個(gè)線(xiàn)程；如果所有線(xiàn)程都已使用，后面的頁(yè)請求將被放置在隊列中。通過(guò)用性能監視器監視總的隊列長(cháng)度，可以確定有多少客戶(hù)端正在等待服務(wù)器的響應。
兩個(gè)最常見(jiàn)的與壓力有關(guān)的非硬件數據庫問(wèn)題是死鎖和鎖定并發(fā)。在數據服務(wù)器上，使用數據存儲區將提供的自定義性能監視器計數器時(shí)，應該至少監視下列內容：
Web 應用程序也應配置成利用 OLE DB 資源池，該資源池由 Microsoft SQL Server 7.0 的中間層 OLE DB 提供程序自動(dòng)管理。通過(guò)基于每頁(yè)創(chuàng )建連接對象并立即釋放它們，數據庫可以處理數千個(gè)并發(fā)用戶(hù)，而使用的開(kāi)放式數據庫連接數少得多。這可保留數據庫資源并提 供更大的可縮放性。應通過(guò)跟蹤數據服務(wù)器上的用戶(hù)連接數（使用性能監視器）監視此性能增強。隨著(zhù)吞吐量增加，當池控制數據服務(wù)器上實(shí)際創(chuàng )建的連接數時(shí)，用 戶(hù)連接數應保持穩定。
針對數據庫調節應用程序的過(guò)程對實(shí)現性能目標至關(guān)重要，并且必須作為因素計入開(kāi)發(fā)循環(huán)。這應包括優(yōu)化分配內存的大小、應用程序在磁盤(pán)驅動(dòng)器和控制器上的分布以及 ActiveX 組件的計算機位置。要特別考慮盡可能消除進(jìn)程間的數據封送處理，因為這是非常昂貴的操作。
運行壓力測試的時(shí)間應比應用程序在實(shí)際用戶(hù)環(huán)境中不中斷運行的預計時(shí)間長(cháng)百分之五十。許多問(wèn)題，尤其是內存泄漏，只有在應用程序運行時(shí)間超過(guò)預期時(shí)間后才會(huì )暴露出來(lái)。
每個(gè)性能監視器計數器的平均值取決于特定的應用程序和硬件配置。因此，當壓力測試運行時(shí)，應該檢查每個(gè)計數器中是否有任何偏離這些平均值的異常偏差。
當查找瓶頸時(shí)，在 Internet Information Server 計算機上監視的最重要方面如下：
根據設計的應用程序環(huán)境，在壓力測試期間可能還有其他要跟蹤的性能方面。下列任何可能的情況可能表明應用程序有問(wèn)題，在最終發(fā)布前應修復這些問(wèn)題。
CPU 使用率
CPU 使用率的減少可能表明應用程序性能的降低，可能是線(xiàn)程爭用問(wèn)題。
當監視用戶(hù)時(shí)間和內核時(shí)間之間的 CPU 時(shí)間比時(shí)，記住作為規則，用戶(hù)時(shí)間應是 CPU 總時(shí)間的百分之八十至九十。因此，超過(guò)百分之二十的內核模式時(shí)間表明有內核級別 API 調用爭用。
為了使計算機物有所值，應該在峰值負載期間注冊超過(guò)百分之五十的處理器使用率。更低的使用率值可能提示您需要解決系統中的其他瓶頸。
內存使用
內存使用暴漲或逐步增加是另外一個(gè)問(wèn)題，這個(gè)問(wèn)題經(jīng)常被認為是長(cháng)期運行的服務(wù)器應用程序的常見(jiàn)問(wèn)題。通常，這是內存和資源泄漏在測試階段暴露出來(lái)的地方。
吞吐量
監視 Active Server Pages 每秒請求數計數器使您得以確定應用程序開(kāi)始什么時(shí)候以及是否有性能問(wèn)題。該計數器在實(shí)際的應用程序中通常有所不同，但是通過(guò)認真地設置線(xiàn)程數和并發(fā)連接數 （例如，通過(guò) Web 應用程序壓力工具配置屏幕進(jìn)行設置），將能夠模擬穩定的請求數。該計數器值的突然減少預示著(zhù)麻煩。
可選測試方面
下面的是壓力測試期間可能發(fā)現值得監視的其他方面的示例：
內部處理數據服務(wù)器的各種 MDAC 服務(wù)和格式化用于顯示的數據通常會(huì )消耗專(zhuān)用于 Web 應用程序的大多數可用服務(wù)器資源。因此，當對應用程序進(jìn)行壓力測試時(shí)，如果與應用程序的數據訪(fǎng)問(wèn)和數據操作區域有關(guān)，則必須特別考慮這些組件的性能。
數據庫用戶(hù)連接、鎖爭用和死鎖是數據服務(wù)器上要監視的主要對象。定期查看數據庫的管理控制臺中的進(jìn)程信息（例如，在運行 SQL Server 的計算機上，是在 SQL 企業(yè)管理器的 Current Activity 區域中)。檢查阻塞的服務(wù)器進(jìn)程 ID，它是不返回響應的數據查詢(xún)的常見(jiàn)原因。這是個(gè)爭用問(wèn)題，并且通常要求對數據庫設計或應用程序邏輯進(jìn)行重大更改。
可以用不同的方法識別死鎖。識別死鎖的最常用的方法是使用性能監視器中的 Number of Deadlocks/sec 自定義計數器。應用程序應該已經(jīng)檢查死鎖問(wèn)題并適當響應，因為允許數據服務(wù)器指定死鎖受害人（即，將被取消以解決死鎖的用戶(hù)或會(huì )話(huà)）會(huì )引起應用程序問(wèn)題。 應用程序應在遇到死鎖時(shí)檢測死鎖情況，并相應響應。遇到死鎖時(shí)一般做法是等待幾毫秒，然后再重試操作；通常，死鎖僅是對時(shí)間敏感的錯誤，當重試操作時(shí)該錯 誤將會(huì )消失。
當完成壓力測試并且測試結果可用于檢查時(shí)，目標性能基準與測試期間收集的統計的比較將指出所需要的更改，以確保用戶(hù)將需要的吞吐量。以下是需要進(jìn)行性能改正應檢查和計算的特定方面：
也許增加應用程序吞吐量最簡(jiǎn)單和最經(jīng)濟的解決方案是硬件升級。通常，升級硬件比付錢(qián)給開(kāi)發(fā)人員團隊重寫(xiě)部分應用程序要經(jīng)濟高效得多。例如，只是通過(guò) 將更多的 RAM 添加到服務(wù)器，您可以使應用程序的吞吐量加倍。然而，如果測試結果表明 CPU 使用率是瓶頸，則升級可能更貴，因為可能必須升級整個(gè)計算機來(lái)增加 CPU 的使用數量與速度。
其他與硬件有關(guān)的增強包括增加硬盤(pán)和控制器的速度以及添加更快或附加的網(wǎng)絡(luò )接口卡。
當計算有關(guān)數據庫設計的問(wèn)題時(shí)，請尋找作用點(diǎn)。分析死鎖統計，并確認已經(jīng)優(yōu)化了應用程序以盡可能避免死鎖。如果有必要，請考慮更改數據訪(fǎng)問(wèn)算法以避免爭用。用不同的索引解決方案進(jìn)行實(shí)驗。檢查數據服務(wù)器的查詢(xún)執行計劃以確認查詢(xún)正在使用適當的索引，等等。
應認真分析包含對 ActiveX 數據對象類(lèi)型庫的引用的 ActiveX 組件以進(jìn)行可能的優(yōu)化。不要使用 ADO 中允許的默認屬性。為避免意外使用默認屬性，應總是指定某些屬性，例如，Cursor Type 和 Cursor Location 屬性。
如果 Web 應用程序消耗了異乎尋常的大量?jì)却?，則游標定位的不適當使用可能就是問(wèn)題的原因。當使用客戶(hù)端游標 (recordset.cursorlocation = adUseClient) 時(shí)，注意客戶(hù)端實(shí)際是 Internet Information Server，而不是瀏覽器。（該規則的例外情況是當使用 Remote Data Services 時(shí)，本文不對此進(jìn)行討論。）開(kāi)發(fā)人員常犯的錯誤是假定客戶(hù)端游標的使用將整個(gè)記錄集移動(dòng)到瀏覽器而不是運行 IIS 的計算機。因此，記住您實(shí)際正在將記錄集存儲到運行 IIS 的計算機上將使您更多地意識到所用的資源。
例如，如果應用程序要求訪(fǎng)問(wèn)列出有效州或縣代碼的表并且該信息存儲在數據服務(wù)器中，則使用客戶(hù)端游標創(chuàng )建駐留在 IIS 計算機上的記錄集，然后本地訪(fǎng)問(wèn)該代碼將更有效，這樣避免了當應用程序訪(fǎng)問(wèn)該信息時(shí)需要另外往返于數據服務(wù)器。一定要注意利弊關(guān)系，如果內存不可用，則不 要以大內存要求加重 IIS 的負載。
如果包含數據訪(fǎng)問(wèn)過(guò)程的 ASP 頁(yè)花費太長(cháng)時(shí)間執行，則可能需要將數據訪(fǎng)問(wèn)代碼從 ASP 頁(yè)移動(dòng)到 ActiveX 組件，該組件一般放置在 Microsoft Transaction Server（在 Windows NT 中）的包中或 Component Services（在 Windows 2000 中）的包中，這取決于正在運行的操作系統。該編輯代碼運行效率比包含在 Active Server Page 中的解釋腳本代碼有效得多。
監視正使用 Internet Information Server 的應用程序數量和類(lèi)型?？赡苄枰砑痈郊拥姆?wù)器，將應用程序移動(dòng)到另一服務(wù)器，或者考慮實(shí)現 Windows Load Balancing Service。
Internet 使您的應用程序可以比傳統的客戶(hù)端－服務(wù)器應用程序面向更多的潛在用戶(hù)。隨著(zhù)越來(lái)越多的組織將 Web 作為他們業(yè)務(wù)策略的策略部分，他們需要確保他們選擇的技術(shù)可以處理他們苛求的需要。除了容易使用的工具，這些組織還需要基礎結構來(lái)滿(mǎn)足他們用戶(hù)負載要求。 因此，壓力測試是測試體系的基礎部分這個(gè)理念比以前更重要，特別是當將 MDAC 合并到應用程序中時(shí)。
注意在壓力情況下成功運行的基本要求是在開(kāi)發(fā)周期中采取最佳慣例方法。這就意味著(zhù)為負載條件下的性能測試和調整應用程序以達到性能目標的時(shí)間調度必須考慮到開(kāi)發(fā)過(guò)程中。
負載下的壓力測試和反復調節應用程序的好處是簡(jiǎn)單明了：
聯(lián)系客服
