javascript:resizepic(this)" width="433" border="0" height="339">
搭建測試環境的示意圖
鮑勃推動的新訂單程序上線后，系統變慢。董事會擔心因此影響生意和聲譽。鮑勃費盡周折查出原因在后臺數據庫，然而在測試環境下卻沒有什么不正常的。鮑勃最終能解決系統變慢的問題嗎？
在鮑勃的推動下，公司的訂單系統經歷了一個非�？焖俚�開發流程，很快就集成到在線店面中去了。不久，他發現，銷售系統的運行有些異常：查詢每條在線訂單的時候，前臺Web服務器從后臺數據庫中讀取數據的時間徒然上升，而且容易出錯，響應客戶請求方面也顯得緩慢。
與此同時，當Mira（鮑勃的新同事）開始為電子商務程序更新模塊時，系統終于不堪重負，倒下了。鮑勃和Mira感到了壓力：董事會擔心，因為系統緩慢，一些用戶會散播謠言，使公司的信譽度下降，以至會影響上市的進度。
為什么我們把系統放在生產網絡中，大家都用得很好的時候，系統卻變慢了？鮑勃想改變這個系統越用越慢的情況，他該如何做呢？
根源在后臺數據庫
由于鮑勃曾經管理過比較復雜的網絡系統，他知道，用戶反映系統出現故障時，一步一步去確定系統的各個環節是否有問題非常麻煩，有很多工作要做：檢查交換機和路由器，Ping操作系統，檢查數據庫服務器，檢查數據庫是否正常（如日志已滿），檢查IIS及App Pool是否異常，檢查自定義的Socket程序是否正常等等……
鮑勃訂購了System Center Operation Manager 2007 ，這樣可以通過自定義分布式應用程序，把所有應用程序整合在一起，系統會自動監控每臺服務器的工作環節。如果有問題，系統會及時讓整個工作小組的開發和維護人員同時收到通知。但時間緊迫，董事會并不允許他等到這個新產品上線。
在確定排除了Web服務器CPU和內存可能存在的瓶頸之后，針對Web服務器上的IIS 6.0 ，鮑勃要求開發小組改寫了三個Monitor腳本，其中使用兩個Monitor腳本收集系統信息：IIsmDyn.js和IIsmStat.js。以IIsmDyn.js腳本為例，這個腳本可以檢索系統性能信息和系統事件信息，這樣可以避免維護人員通過手工訪問性能監視器或事件查看器。該腳本會檢索來自以下源頭的事件查看器條目：WAS（Web 管理服務）、W3CTRS（World Wide Web 計數器）、W3SVC（World Wide Web 發布）等。
工作小組重新利用壓力測試軟件對Web服務器上的靜態頁面進行測試。監控腳本在Web服務器上布控了3天零19個小時，幾次測試的結果都表明，每臺服務器的處理能力都維持在每秒80.20次請求的級別上，CPU的利用率約為65%左右，這相當于2100～2500名并發訪問用戶的情況。但是監控腳本中并沒有直接提供警告的信息，人們帶著懷疑的心理對后臺數據庫進行性能測試。剛一開始，服務器就緩慢下來，鮑勃和Mira的眼睛都盯在后臺數據庫服務器上了。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
