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計數器會上下變動。因此，如果總隊列長度從不增加且您正以低處理器使用率運行，這可能表明站點運行平穩，具有的容量比該壓力負載需要的大�；蛘�，如果隊列長度正在上下變動但是處理器使用率低于百分之五十，這可能表明一些請求正被阻塞，可能需要進一步優化。 瀏覽器響應時間�？梢远ㄆ趶臑g覽器訪問 Active Server Pages 以監視響應時間并確保壓力測試正在正確運行，并且 Web 站點仍可以正確地服務 ASP 頁。建議在壓力測試期間每天至少執行兩次此測試。 超時錯誤。在瀏覽器測試期間，留心由 Internet Information Server 返回的超時錯誤；這些錯誤可能表明有太多用戶正同時訪問應用程序。監視數據服務器
文章來源于領測軟件測試網 http://www.kjueaiud.com/
