我們正在使用一個大約有 300 個並髮用戶的應用程式。現在一切都已虛擬化：1 個虛擬機器作為負載平衡器，2 個虛擬機器作為 Web 伺服器（在此 ESXi 主機上還有另外 25 個其他虛擬機器）和 1 個伺服器（裸機）作為 SQL Server。我們的效能存在一些問題，因此決定購買實體硬體來提高效能。
我不確定，我們如何才能獲得更好的性能？
我們購買 1 個機架伺服器硬體並僅使用上述所有 3 個虛擬機器運行 ESXi，
我們為 Web 伺服器購買 1-1 機架伺服器硬件，並僅使用應用程式安裝 Windows 伺服器。 （並像以前一樣保留負載平衡器 - VM）
- 我們購買 3 台機架伺服器用於負載平衡器和 2 台 Web 伺服器。
使用者透過網頁介面/桌面應用程式連接到伺服器。
謝謝你的幫助，德魯
答案1
在決定前進的道路之前，您應該找到一些資訊的答案：
受影響虛擬機器的 CPU 使用率
- 從客戶作業系統的角度來看，CPU 使用率是否經常高於 80%，和/或顯示使用率處於穩定狀態而不是高峰？您的虛擬機器可能 CPU 資源匱乏。添加更多 vCPU（但請考慮可能的許可問題）。
- 您伺服器中的某些 vCPU 的負載是否明顯低於其他 vCPU？您的應用程式中可能會遇到擴充問題，簡單地將更多 vCPU 放入單一虛擬機器（或實體機）中並不能解決問題。
- 時間是否
CPU ready表示主機過度使用？您有時會看到的一條經驗法則是您希望平均就緒時間少於5%，但我的經驗是，即使這樣對於您實際工作的系統來說也太多了。指示的就緒時間是自上次圖表更新以來的總毫秒數。在「即時」檢視中，圖表每 20 秒（= 20000 毫秒）更新一次，因此可以使用下列公式計算 VM 的每個 CPU 的平均百分比(indicated_ready_time * 100 / 20000) / number_of_vcpu。
記憶體使用情況
（應始終從來賓作業系統內檢查）
- 一般都在80%以上？添加內存。
- 內存洩漏的跡象？修復應用程式或準備更頻繁地重新啟動/重新啟動。
- 大量交換的跡象？檢查配置問題。添加內存。
- 您是否有「莫名其妙」使用少於 4 GB 記憶體的關鍵應用程式/進程？它們可能需要重建或重新配置才能利用 64 位元尋址。
也要檢查磁碟和網路效能是否有延遲問題。
根據應用程式的擴展方式，添加更多 Web 伺服器可能比向現有伺服器添加運算能力或記憶體更好。
一旦您了解了瓶頸在哪裡以及如何最好地利用硬件，您就可以開始製定購買內容的業務案例。
虛擬機器的主要優點是它們更易於管理、更易於備份並且在系統故障時更易於遷移。它們可以更好地利用您的硬件，前提是它們實際上不需要您可以投入的所有資源，並且如果您使用半虛擬化網絡接口，同一主機上的計算機之間的通信速度與CPU 可以管理的速度一樣快受限於實體網路介面速度。
當然，直接在實體機上運行的系統不會因為資源共享而產生任何開銷，但這只是在您可以使用可用電源的情況下的好處。
答案2
如果您不調查效能問題的原因和對應用程式的了解，您就無法判斷什麼是最簡單/最好的補救措施。
如果您的問題確實是缺乏硬體資源，那麼監控應該可以清楚地表明您現在在哪裡達到了限制以及要購買什麼（CPU 核心或CPU 速度、更多RAM 記憶體、更快的磁碟）以及將其分配到哪裡。
根據我的經驗，超過一半的效能問題或多或少可以透過適當的調整輕鬆解決，而不是投入更多的硬體資源來解決問題。大多數開發人員和太多供應商沒有能力或資源來使用與生產中獲得的相同數量的數據和相似的負載來測試他們的應用程式和資料庫後端，並且他們所做的假設和設計選擇也無法擴展實踐中效果良好。
仔細的監控將使您深入了解瓶頸是什麼以及您可能需要在應用程式、資料庫或硬體層級解決什麼問題。
請注意，性能分析和調優既是一門科學，也是一門黑術。
非常常見的應用程式問題可以輕鬆解決，並且通常可以帶來顯著的好處：
- 資料庫中缺少索引
- 連接池和查詢快取
- 調整應用程式的記憶體限制、連接數、套接字和並發線程
應用程式設計中更難以解決的缺陷是應用程式前端中有太多資料處理邏輯，資料庫查詢太簡單、未綁定並返回太多資料（例如使用 a SELECT * from GrowingDataSet） - 在監控症狀時例如資料庫伺服器上的高磁碟IO 負載- 應用程式伺服器上的高記憶體消耗- 飽和的網路連結- 其中每一個都可用於支援不同的硬體購買決策（在資料庫伺服器中升級到SSD - 增加應用程式伺服器中的RAM - 升級網路）當應用程式開始在查詢中應用更好的邏輯和分頁時，可能不需要這些。