內部處理數據服務器的各種 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 合并到應用程序中時。
注意在壓力情況下成功運行的基本要求是在開發周期中采取最佳慣例方法。這就意味著為負載條件下的性能測試和調整應用程序以達到性能目標的時間調度必須考慮到開發過程中。負載下的壓力測試和反復調節應用程序的好處是簡單明了： 獲得需要的信息以確保應用程序取得最好的吞吐量結果。 可以精確地評定應用程序的可縮放性特征，以便可以調整應用程序達到指定的性能目標。 可以盡早發現降低性能和吞吐量的設計問題，并且在將應用程序部署到生產之前可以進行調整。 應用程序將因為其高性能可信賴性而在客戶與業務伙伴中樹立起聲譽。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
