一臺服務器上ASP.NET網站的最大數量/限制

我的問題很簡單。大約兩年前，我們開始從ASP Classic遷移到ASP.NET。我們的問題是，我們目前在服務器上有大約350個站點，服務器似乎陷入困境。我們一直在嘗試不同的事情，以改善性能，查詢優化，禁用ViewState的，會話狀態，等他們都工作過，但是我們添加更多的網站，我們最終會使用更多的服務器資源，所以我們在代碼中所做的改進實際上已被刪除。一臺服務器上ASP.NET網站的最大數量/限制

基本上我們現在處於轉折點，我們的CPU目前平均接近100％。我們的IS希望我們能夠找到新的方法來改寫網站上的代碼以提高性能。

我有一個理論，我們只是在一個服務器可以處理的網站數量的限制。

任何想法？如果你對你正在談論的內容有一個好的想法，請僅迴應。我聽到很多人關於這個電臺的理論。我需要一個對可能發生的事情有實際知識的人。

這是細節。

250 ASP.NET網站
250聯繫網站（用ASP.NET編寫的，基本上他們是後臺管理網站）
100經典ASP網站

運行虛擬化的Windows服務器上

3個CPU，4GB內存。
記憶保持約3 - 3.5 GB
的CPU穗非常厲害，有時它們保持接近100％的時間短的時間（30 - 180秒）

該數據庫是一個單獨的服務器上，並且是SQL SERVER 2005.

來源

2011-12-09 matwonk

取決於服務器和代碼，您可以在一臺服務器上放置比您描述的更多的網站，但由於我們對源代碼不瞭解（是.NET 2還是4？它究竟做了什麼？）和「虛擬機內部的CPU峯值」不是一個真正的診斷事情，答案只是純粹的猜測...... – Yahia

天哪，你試圖在玩具服務器上運行這麼多的網站？這不是關於asp.net的可擴展性，而是關於「我可以得到多少便宜」。這裏有一個提示 - 至少有一個體面的工作站 - 16GB內存。然後獲得足夠的光盤進行體面的IO。那麼回來問問。 – TomTom

*「如果你對自己所談論的事情有一個好的想法，請回答，我聽到很多人對電臺的理論，我需要一個對實際情況有實際認識的人。」*開玩笑吧？你沒有給我們任何信息繼續做出這樣的答案。我們必須要知道這一點。這就是說......你可能是對的。或者，你可能是錯的。 –

看起來你已經達到了這一點。您已經優化了您的應用程序，您已經查看了服務器性能，可以看到您正在達到峯值內存使用率，最大限度地利用CPU，並且讓我們面對它，管理這麼多網站並不容易。

此外，您的VM的規格並不是太棒了。這是內存，尤其是對於您擁有的網站數量來說可能不是很好。

您有充足的理由移動。

然而，有些東西看：

1）有多少的250個網站的實際使用？哪些人是高峯表現罪犯？那些人是被移出他們自己的盒子的主要候選人。

2）根本沒有使用多少？你可以退休嗎？

3）您正在虛擬機上運行。你在使用什麼樣的虛擬機平臺？該硬件上還有哪些其他服務器正在運行？

4）您目前有什麼樣的冗餘？一個盒子裏有250個網站，沒有備份？如果您有備份服務器，則可以使用該服務器來輪詢循環請求，或者將其用作Web場，以共享負載。

讓我們說你決定搬家。你應該考慮的第一件事是如何。

你打算簡單地減少一些網站？一個盒子上有125個管理員，另一個上面有125個管理員？或者你會移動使用最多的？

或者您可以將多個虛擬機全部激活，作爲Web場或負載平衡系統的一部分。但是，從事物的聲音來看，購買更多硬件存在着真正的抵觸情緒。

在某些時候，你將不得不雖然，有時候，事情就會變老或被遺忘。新服務器在同一空間內具有更多的處理能力和內存，並且可以更便宜地運行。

哦，還有一件事。所有這些重複優化和測試的成本可能很容易被購買更多硬件所抵消。當然，沒有任何理由不做任何優化，我對你正在運行的網站數量印象深刻，特別是如果你有很多用戶，但是有一個平衡點，我希望你可以傾向於更「硬件」的一面。

來源

2011-12-09 21:02:16 dash

我認爲你真的已經回答了你自己的問題。您已優化網站，您已將數據庫服務器安裝在不同的服務器上。你有600個網站（250 + 250 + 100）。

答案對我來說很清楚。購買更多內存和CPU功率的盒子。

來源

2011-12-09 20:54:13

他不需要不同的服務器。他需要一些你可以在商店買到的東西。哎呀，他的「服務器」甚至不是一個體面的虛擬機。我爲我的開發環境運行了一個虛擬機，比這個玩具虛擬機安裝程序的功能強大多了。 – TomTom

但它可以運行孤島危機嗎？ ;-)我認爲規範對所有事情都很輕鬆，特別是RAM，但是使用低功率機器的農場可能是一個體面的妥協。 – dash

我的家用臺式機甚至更好......以及我工作中的服務器 – Ruben

只要考慮一下這個問題，看起來好像衡量的是打到服務器的用戶數而不是＃個用戶數。你可以有300個網站，只有一半被使用。知道使用情況在我看來會更好。

來源

2011-12-09 20:55:14 uadrive

對於服務器可以處理的站點數量沒有實際限制，如果所有600個站點都沒有用戶，那麼服務器上的負載就不會很大。

我想你可能會在serverfault找到更好的答案，但這裏是我的2美分。

您可以放大或縮小。

向上擴展 - 在CPU中具有更多內存/更多內核的機器升級。向外擴展 - 通過在兩臺或更多臺服務器上分割網站來分配負載。服務器A上有300個，服務器B上有300個，每個服務器上有200個。

正如@uadrive提到的，這是一個加載問題，而不是＃個網站。

來源

2011-12-09 21:00:11 danludwig

有沒有簡單的公式答案，如「每個RAM最多可以有47.3個站點」。如果每個站點每天只有一個用戶，那麼您可以確保保持更多站點的性能。有可能只有兩個站點的服務器，但性能很差，因爲每個命中需要大量的數據庫查詢。

實際上，解決這個問題的唯一方法是經驗性的：當性能開始下降時，就會出現問題。事實上，有人在某本書的某本書中寫道，如果在實踐中，您的服務器無法支持您的站點和您的用戶，那麼具有此類資源的服務器應該能夠支持更多的站點。

現實的選擇是：

（a）優化您的代碼和數據庫查詢。你說你已經做到了。也許你可以做更多。你的代碼現在不太可能是絕對最好的，但它很可能是尋求進一步改進的努力將是非常昂貴的。

（b）購買更大的服務器。

（c）在多個服務器上分割您的網站，並更新DNS或安裝前端以將請求映射到正確的服務器。

來源

2011-12-09 21:06:56 Jay

最大限度地利用CPU可能是一個好兆頭，從某種意義上說，遷移到大型服務器或在多個服務器之間劃分站點可能會有所幫助。

有很多事情可以幫助提高性能和可伸縮性（事實上，我已經寫了一本關於此主題的書 - 請參閱我的配置文件）。

這很難作出有意義的建議，不知道更多關於你的應用程序，但這裏有幾個簡單的技巧，可以幫助您開始：

多個AppPools是昂貴的。每個AppPool有多少個網站？減少客戶端往返次數：改善客戶端和代理級緩存，將靜態文件卸載到CDN，使用圖像精靈，合併多個CSS和JS文件
在頁面上啓用輸出緩存和/或控制可能
對靜態文件啓用壓縮（第一次訪問時使用更多CPU，但在此之後次數減少）
如果可以，請避免使用會話狀態（更喜歡使用Cookie進行狀態管理）。如果你不能，那麼至少爲不需要編寫頁面的頁面配置EnableSessionState =「ReadOnly」會話狀態，或者根本不需要配置的頁面配置爲「false」
SQL上的很多事情服務器端：緩存，SqlCacheDependency，命令批處理，將多個插入/更新/刪除分組到單個事務中，使用存儲過程而不是動態SQL，使用異步ADO.NET而不是LINQ或EF，確保您的數據庫日誌位於單獨的主軸上從數據等
尋找與您的代碼算法問題;例如，散列表通常比線性搜索更好，等等。
最小化cookie大小，只在頁面上設置cookie，而不在靜態內容上設置。

此外，使用虛擬機很可能會使性能成本高達10％左右 - 確保它在購買改進的可管理性方面確實值得。

來源

2012-01-02 06:49:45 RickNZ

一臺服務器上ASP.NET網站的最大數量/限制

回答

相關問題