長期以來，我們一直在倡導這樣的觀念：即使你的預算充足，添置硬件通常不是正確的解決方案，即使這也是一個有效的方案。通過主動實施系統的方法論來了解你的環境容量，在問題影響到你的最終用戶之前，你可以避免被動地解決問題并且可以根據你的具體環境做出有根據的決定。
容量評估不只是負載測試。在準備好執行容量評估之前還需要準備下面內容：
均衡的，典型的服務請求: 需要了解你的用戶，特別要知道他們的操作以及操作的百分比(均衡的)。 明確SLA：需要為關鍵服務請求定義精確的SLA。 期望的負載：需要知道應用所要支持的并發用戶的數量。包括典型的行為，譬如與你的負載測試有關的思考時間。 漸進的負載產生工具：需要產生負載的應用可以在合理的時間內達到你期望的負載，然后再緩慢增加。 SLA評價：該功能可以被內置在你的負載產生工具中或者由綜合事務分析提供或是通過完成綜合性的事務, 但重點是基于他們各自的SLA監測服務請求的響應時間。 資源利用率的監測：采集應用服務器的性能和操作系統資源利用率，以此確定資源利用率的飽和點，以及最先飽和的資源。在調優的的過程中，這種信息能幫助你確定何處更需要調優。在掌握了所有這些數據后, 就可以開始對應用施加負載了。配置你的負載產生工具，在合理的時間(可以象10 分鐘那么短，或像一個小時那么長，或根據在上線環境里觀察到的用戶行為)內，產生你期望的使用壓力。在將負載增加到期望的負載過程中，應采集服務請求的響應時間并且基于他們的SLA進行評價。
一旦達到預期的用戶負載，就可以確定你想要監測步驟的大小了。步驟的大小是在采樣間隔之間增加的可測量的用戶負載，定義了容量評估的精確粒度。例如，所期望的負載是1000 用戶，你可以定義一個步驟為25或50名用戶。在一個時間段中逐漸增加步驟，然后在這些時間段中記錄服務請求的響應時間。
對每個服務請求都采用這種模式，直到每個請求的響應時間超過它的SLA。需要注意這個時間并且開始以更短的間隔記錄響應時間。增加采樣的目的是，在達到它的容量之后，能夠更好的識別一個服務請求是如何遞降的。從這些遞降的數字中，我們要盡量繪出響應時間，從而確定下降的程度：是線形下降？指數或更壞？這里的關鍵是我們了解未達到SLA所隱含的問題。
例如，如果在1500用戶時，我們沒達到SLA, 但是在增加下一個500名用戶時，只增加了50%的響應時間，那么這要好于：每增加100用戶就增加三倍的響應時間，然后在1800用戶時整個應用服務器崩潰。這可以幫助我們了解和減輕由用戶行為的變化而導致的風險。
對每一個服務請求，我們都匯總這種信息并且以最小公分母的方式關注應用的容量：即所有服務請求開始到未達到它的SLA。在在容量分析報告的下個部分，描述了性能遞降應用的行為。從這個報告當中，業務負責人可以確定他們何時需要增加額外的資源。
當進行測試時，還需要監測應用服務器和操作系統資源的使用率。需要知道線程池，堆，JDBC連接池，以及其它后端資源連接池(比如：JCA 和JMS), 和緩存，還有CPU，內存, 硬盤I/O 和網絡活動等的使用率。
圖1: 用戶負載，服務請求響應時間，和資源利用率之間的關系。圖1 把用戶負載、服務請求響應時間和資源利用率關聯了起來。你可以看到，當用戶負載增加, 響應時間也緩慢的增加，而資源利用率幾乎是線形增長。這是因為應用做更多的工作，它需要更多的資源。一旦資源利用率接近百分之百時，出現一個有趣的現象--響應以指數曲線方式下降。這點在容量評估中被作為飽和點。飽和點是指所有性能指標都不滿足，隨后應用發生恐慌的時間點。執行容量評估的目標是保證你知道這點在哪，并且你應該永遠不要出現這種情況。在這種負載發生前，你應調優系統或者增加適當額外的硬件。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
