（1）分而治之
大型的電子商務系統可能非常復雜，包含全球各主要地點的數據中心、全球廣域網絡、數據中心的當地交換局域網絡、安全基礎設施、各數據中心的計算基礎設施、存儲子系統、分布式的數據庫系統等。從系統設計的角度講，復雜系統的設計通常采用自頂向下的模塊化、層次化的構架設計。層次是基于結構的一種劃分，模塊式基于功能的一種劃分。復雜系統可以先基于層次劃分，然后在每一層次中細分功能模塊；也可以先基于模塊劃分子系統，然后在子系統內部再劃分。
這種設計思路簡化了問題的復雜度，比較好的控制了再設計的每一階段需要同時考慮的因素的數量。電子商務系統的容量規劃，對應系統架構的分解，也可以分而治之，對各層次、各模塊的性能分別進行容量規劃。具體到各層次、各模塊。他們對預期容量、性能、擴展性的要求都是不一樣的，分而治之也可以確保容量規劃考慮到足夠細致。
另外，分而治之能幫助把握容量規劃的重點。根據8/2原則，整體系統的性能的瓶頸，往往取決于系統20%的組建，分而治之幫助找到系統中的需要關注的層次和模塊，在容量規劃中對這些層次和模塊加以重點考慮，往往能達到事半功倍的效果。
（2）利用工具
容量規劃即是科學，又是一種藝術，因為沒有人能精確預測實際的容量需求。利用工具可以幫助預測和分析電子商務系統的行為和需求發展趨勢，為容量規劃提供樣本數據，為理論計算提供實際數據參考。
在兩類工具可以幫助容量規劃。一類是測試工具，通常在系統部署上線和升級之前使用，用于模擬用戶用戶實際實際的訪問請求，可以用來測試和觀察系統在接近真實訪問請求的情況下的行為和性能。模擬一定數量的并發訪問，可以用來做壓力測試，幫助測試觀察系統在不同的負載下的行為和處理能力的變化情況、趨勢和飽和點。這些數據都可以極大地幫助到容量的分析和預測。常用的工具如，微軟的免費工具web capacity analysis tool 和web application stress tool。
另一類是檢測工具，通常在系統運維階段使用，用于監視系統的實際訪問量和使用率，觀察訪問需求和峰谷值特征和變化趨勢，幫助警告系統容量接近上限是否需要擴充，幫助預測一定周期內訪問量和增長趨勢，便于對可預見的將來系統的進一步升級進行規劃。某些工具還可以自動進行某些預測分析，預告未來幾個月、半年、一年的容量需求。
3）動態調整
即使在系統上線前進行了非常細致的容量規劃，系統真正開始運行后，仍然可能發現與實際情況有差異。另外，伴隨電子商務業務的快速發展，系統訪問需求的變化也可能很快超過預期值。所以，容量規劃是一個長期的任務，韻味人員需要定期評估系統的負載、利用率、訪問需求的變化情況和趨勢，有必要的話應提出擴充升級的需求。定期的評估可以使用監控工具的數據，也可以通過理論分析，依據新的需求開展。
下面介紹容量規劃需要考慮的一些主要因素。
1）用戶數量
確定同時使用站點的用戶數量，這個數字通常有兩個主要來源：市場分析和系統分析。如果站點還未建立或者發布，站點所有者和操作人員就可能需要借助市場分析報告來預測站點發布初期及以后的預期通信量。如果站點已經建立且已在運行，分析web服務器的日志文件，以了解站點在不同時間的點擊數以及可以表明站點內容很受歡迎程度是否增加的所有使用趨勢。計算站點當前支持的用戶數量時，要根據峰值使用來計算，而不是根據典型使用平均或者平均使用。
這里隱含了一個可用性的問題。企業應對網站可用性程度做出決策。例如，是必須保證網站能處理峰值的訪問量，還是保證能處理80%的峰值訪問量就夠了？這取決于公司打算投入多少財力來保證電子商務系統始終能夠滿足需求。這要看電子商務網站不可用而引起的損失是否值得企業花錢來達到這種可能性。
2）頁面類型
如果web服務已處理靜態頁面為主，由于靜態頁面讀取主要看磁盤操作，所以更多考慮的是I/O性能要求，如果web服務需要處理大量動態頁面，那么對中間件系統計算能力和數據庫處理能力的要求就會比較高，生成動態內容所需的數據查詢處理量越大，對系統計算能力和數據庫處理能力要求就越高。
3）采用何種web應用技術
采用asp、asp.net java、applet、jsp、web service 等不同的微博應用技術，對系統的處理能力開銷是不一樣的。
4）網站提供的服務內容
例如，通過電子商務提供法律咨詢的服務的網站，網頁的內容可能多數以文字為主，有少量圖片，那么同樣的條件下，用戶調用某一頁面的時間會比較短，每一用戶請求占有系統的處理能力資源會比較少。而如果是通過電子商務提供視頻、圖片資料服務的網站，網頁內頁以圖片、視頻資料為主，可能帶有實時傳送的流媒體內容，那么用戶調用某一頁面的時間比較長，每一用戶請求占有系統處理能力資源也會比較多。
對于電子商務網站的基礎設計，每一組建，包括web和中間件系統、數據庫系統、服務器系統、存儲系統、網絡系統的容量規劃，簡化來講，都基于一下的公式：系統容量=并發服務請求數x每請求系統開銷。
