因此，一篇正式的容量評估報告包括以下內容：
基于應用的當前/期望的用戶負載 在均衡和典型的服務請求下的應用的容量 當前負載下的關鍵服務請求的性能 每個服務請求的遞降的模式 系統飽和點 建議在你收集了數據和識別了關鍵點之后(比如：滿足SLA，未滿足SLA，遞降模式，飽和點等)，下一步應該進行更加深入的分析并提出建議。請試將你的應用按下面分類：
極端利用不足的系統：系統可以支持大于50%的額外負載。 利用不足的系統：在當前/期望的負載下，所有服務請求都達到他們的SLA并且系統可以很容易地支持超過25%的額外負載。 臨界容量：應用滿足SLA，但其容量小于當前負載的125%。 過度利用的系統：應用不滿足它的SLA。 極端過度利用的系統：在當前或期望的負載下，系統已經飽和。在極端利用不足的系統中，你可以考慮減少硬件或者服務器的許可，來節省許可費用。是否需要這些額外的容量，這個決定只能由應用業務負責人討論后才能確定。
在利用不足的系統中, 你就可以高枕無憂了，因為你的環境能忍受任何合理的額外負載, 但是，它的利用率也沒有低到需要削減資源的程度。
在臨界的容量系統中, 你需要花費大量的時間和應用業務負責人一起確定用戶行為的未來變化，可預測的用法模式的變化和計劃的促銷等等，從而決定是否需要額外的資源。
在過度利用的系統中, 你需要更多資源。但這一點，仍然由應用業務負責人決定。應用沒有達到SLA的嚴重程度？性能遞降模式是什么? 當前的應用行為是否可接受？設計中的用法變化是否會極大降低應用性能？
在極端過度利用的系統中，你無庸置疑地會受到用戶的抱怨，并且處于前面提到的完全驚慌的狀態。你需要有效的調優并且盡可能得增加額外的資源譬如硬件，來保留住你的用戶。
在重要的應用疊代的結尾，對于所有的應用部署，都應該執行容量評估。一個完善的容量評估采集應用的當前負載的性能，系統容量（當第一次服務請求未達到它的SLA時），服務請求的下降模式和環境的飽和點。從這些信息中, 你能概括出結論，發起關于修改環境的討論。沒有進行容量評估而盲目去做，希望在下一次促銷或節日期間，應用不會崩潰。要求你的管理層批準這些工作，將能保證讓您高枕無憂。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
