在許多企業系統體系結構中，根據併發性工作負載要求來調整硬件大小已勢在必行。大多數產品供應商將提供他們自己的硬件規模表，其中你只需插入指標，它會拋出服務器數量，RAM所需的細節等等。但是，當系統使用開源軟件組件開發時，這樣的指南並不容易獲得。硬件規模 - 拇指規則
我需要做一個系統的硬件大小。該系統可水平擴展，因此可通過添加更多節點來適應不斷增長的流量。首先，系統將有兩個HAProxy負載平衡器節點。負載平衡器後面是提供HTML頁面和JavaScript的Web服務器。有更多節點託管RESTful Web服務的服務器。在後端有一些Cassandra節點。我們對流量或併發用戶有一個粗略的想法。
硬件尺寸選擇應該如何？有沒有一般的指導方針？
這也許是最難回答的問題之一。我正在關注這個主題，看看其他人可能會有什麼想法。
需要考慮產品運行的硬件平臺，操作系統，應用程序服務器，數據庫服務器等，以及產品的相對複雜性。提供靜態HTML的網站將擴展到比OLTP系統更多的用戶。
瞭解目標平臺的先天功能至關重要。知道ASP.NET支持12個併發執行的線程/ CPU（默認配置），你可以使用輸出緩存來大大降低併發性，或超過3,000請求/秒需要千兆以太網到數據庫服務器等，可以幫助你正確地計劃，知道你必須拉動什麼槓桿等。
供應商硬件尺寸表反映了他們花在產品性能和容量測試上的大量工作。對於您正在進行內部開發或非營利開發的應用程序，這可能是一個難題。
總之，您的目標應該是開始製作產品中更復雜區域的POC，然後開始投資於持續的性能和容量規劃迭代。
如果不這樣做，可能會發生故障 - 無法執行，無法執行容量規劃或業務失敗 - 用戶從未到過。
我希望我有更好的答案 - 我自己也面臨着同樣的挑戰。
如果您有第一天就無需部署到所有1,000個用戶的奢侈品，那麼我很樂意使用虛擬化來幫助您解決這個問題。我首先用裸機建立服務器，並根據需要檢查它們的功能。然後使用你喜歡的任何虛擬機軟件的P2V轉換器從物理轉換爲虛擬磁盤映像。然後，我會刪除服務器的原始磁盤並安全地存儲它們，在裏面粘貼一些新的磁盤，安裝您選擇的虛擬機管理程序，添加轉換後的虛擬機，啓動它，爲您的虛擬機/操作系統添加para工具並查看您的工作方式。如果你的服務器工作，那麼你給自己的是可移植性。您可以從一百名左右的用戶開始，測量負載，推斷並做出一些假設。然後添加更多用戶，測試您的假設等等。如果你有1,000個用戶，並且有足夠的空間可以做到這一點，那麼你可以留在虛擬環境中（優點：良好的災難恢復選項，便攜性;缺點：你失去了一些性能），或回到裸機版本處理工作。如果您的機器變得越來越熱，那麼您可以非常輕鬆地將VM移動到更大/更好/更快的硬件，或者將VM複製到另一個物理VM主機和羣集。
我知道這並不直接回答你的問題，但我不確定這是否有經驗法則，因爲基於如此多的因素，每用戶負載有巨大的波動。
如果你有一個月左右的時間，直到你不得不訂購你的服務器，你可能會考慮新的基於Nehalem的Xeons - 他們真的值得等待。
下列幾點可以幫助你
由於Chopper3