很多人在使用諸如"容量評估"，"容量計劃"，"趨勢分析"和"預測" 等術語時，并沒有真正理解這些詞匯的含義。當有人提起"容量計劃"時，通常是指他們的應用不能滿足SLA，而將被迫購買更多的硬件。
長期以來，我們一直在倡導這樣的觀念：即使你的預算充足，添置硬件通常不是正確的解決方案，即使這也是一個有效的方案。通過主動實施系統的方法論來了解你的環境容量，在問題影響到你的最終用戶之前，你可以避免被動地解決問題并且可以根據你的具體環境做出有根據的決定。
容量評估不只是負載測試。在準備好執行容量評估之前還需要準備下面內容：
- 均衡的，典型的服務請求: 需要了解你的用戶，特別要知道他們的操作以及操作的百分比(均衡的)。
- 明確SLA：需要為關鍵服務請求定義精確的SLA。
- 期望的負載：需要知道應用所要支持的并發用戶的數量。包括典型的行為，譬如與你的負載測試有關的思考時間。
- 漸進的負載產生工具：需要產生負載的應用可以在合理的時間內達到你期望的負載，然后再緩慢增加。
- SLA評價：該功能可以被內置在你的負載產生工具中或者由綜合事務分析提供或是通過完成綜合性的事務, 但重點是基于他們各自的SLA監測服務請求的響應時間。
- 資源利用率的監測：采集應用服務器的性能和操作系統資源利用率，以此確定資源利用率的飽和點，以及最先飽和的資源。在調優的的過程中，這種信息能幫助你確定何處更需要調優。
一旦達到預期的用戶負載，就可以確定你想要監測步驟的大小了。步驟的大小是在采樣間隔之間增加的可測量的用戶負載，定義了容量評估的精確粒度。例如，所期望的負載是1000 用戶，你可以定義一個步驟為25或50名用戶。在一個時間段中逐漸增加步驟，然后在這些時間段中記錄服務請求的響應時間。
對每個服務請求都采用這種模式，直到每個請求的響應時間超過它的SLA。需要注意這個時間并且開始以更短的間隔記錄響應時間。增加采樣的目的是，在達到它的容量之后，能夠更好的識別一個服務請求是如何遞降的。從這些遞降的數字中，我們要盡量繪出響應時間，從而確定下降的程度：是線形下降？指數或更壞？這里的關鍵是我們了解未達到SLA所隱含的問題。
例如，如果在1500用戶時，我們沒達到SLA, 但是在增加下一個500名用戶時，只增加了50%的響應時間，那么這要好于：每增加100用戶就增加三倍的響應時間，然后在1800用戶時整個應用服務器崩潰。這可以幫助我們了解和減輕由用戶行為的變化而導致的風險。
對每一個服務請求，我們都匯總這種信息并且以最小公分母的方式關注應用的容量：即所有服務請求開始到未達到它的SLA。在在容量分析報告的下個部分，描述了性能遞降應用的行為。從這個報告當中，業務負責人可以確定他們何時需要增加額外的資源。
當進行測試時，還需要監測應用服務器和操作系統資源的使用率。需要知道線程池，堆，JDBC連接池，以及其它后端資源連接池(比如：JCA 和JMS), 和緩存，還有CPU，內存, 硬盤I/O 和網絡活動等的使用率。
圖1: 用戶負載，服務請求響應時間，和資源利用率之間的關系。
圖1 把用戶負載、服務請求響應時間和資源利用率關聯了起來。你可以看到，當用戶負載增加, 響應時間也緩慢的增加，而資源利用率幾乎是線形增長。這是因為應用做更多的工作，它需要更多的資源。一旦資源利用率接近百分之百時，出現一個有趣的現象--響應以指數曲線方式下降。這點在容量評估中被作為飽和點。飽和點是指所有性能指標都不滿足，隨后應用發生恐慌的時間點。執行容量評估的目標是保證你知道這點在哪，并且你應該永遠不要出現這種情況。在這種負載發生前，你應調優系統或者增加適當額外的硬件。
因此，一篇正式的容量評估報告包括以下內容：
- 基于應用的當前/期望的用戶負載
- 在均衡和典型的服務請求下的應用的容量
- 當前負載下的關鍵服務請求的性能
- 每個服務請求的遞降的模式
- 系統飽和點
- 建議
極端利用不足的系統：系統可以支持大于50%的額外負載。
利用不足的系統：在當前/期望的負載下，所有服務請求都達到他們的SLA并且系統可以很容易地支持超過25%的額外負載。
臨界容量：應用滿足SLA，但其容量小于當前負載的125%。
過度利用的系統：應用不滿足它的SLA。
極端過度利用的系統：在當前或期望的負載下，系統已經飽和。
在極端利用不足的系統中，你可以考慮減少硬件或者服務器的許可，來節省許可費用。是否需要這些額外的容量，這個決定只能由應用業務負責人討論后才能確定。
在利用不足的系統中, 你就可以高枕無憂了，因為你的環境能忍受任何合理的額外負載, 但是，它的利用率也沒有低到需要削減資源的程度。
在臨界的容量系統中, 你需要花費大量的時間和應用業務負責人一起確定用戶行為的未來變化，可預測的用法模式的變化和計劃的促銷等等，從而決定是否需要額外的資源。
在過度利用的系統中, 你需要更多資源。但這一點，仍然由應用業務負責人決定。應用沒有達到SLA的嚴重程度？性能遞降模式是什么? 當前的應用行為是否可接受？設計中的用法變化是否會極大降低應用性能？
在極端過度利用的系統中，你無庸置疑地會受到用戶的抱怨，并且處于前面提到的完全驚慌的狀態。你需要有效的調優并且盡可能得增加額外的資源譬如硬件，來保留住你的用戶。
在重要的應用疊代的結尾，對于所有的應用部署，都應該執行容量評估。一個完善的容量評估采集應用的當前負載的性能，系統容量（當第一次服務請求未達到它的SLA時），服務請求的下降模式和環境的飽和點。從這些信息中, 你能概括出結論，發起關于修改環境的討論。沒有進行容量評估而盲目去做，希望在下一次促銷或節日期間，應用不會崩潰。要求你的管理層批準這些工作，將能保證讓您高枕無憂。
文章來源于領測軟件測試網 http://www.kjueaiud.com/