使用共享ASP.NET應用程序減少IIS設置中的內存開銷

我有三個需要運行的核心ASP.NET應用程序。我使用鏡像的IIS 7.5配置設置了兩臺Windows Server 2008 R2服務器，然後使用負載平衡器指引流量，並將另一臺服務器作爲狀態服務器。這一切都設置和工作（尚未生產）。使用共享ASP.NET應用程序減少IIS設置中的內存開銷

我們有大約120個客戶端（並且在不斷增長），現在我的設置是每個客戶端從IIS根目錄獲取他們自己的虛擬目錄（作爲.NET應用程序）。虛擬目錄應用程序指向磁盤上他們自己的web.config所在的目錄，以存儲連接字符串和一些核心應用程序參數等內容。然後關閉每個客戶端的應用程序，這三個核心ASP.NET應用程序都有一個虛擬目錄應用程序。所以像這樣：

/ (IIS root) 
    /client1 => c:\inetpub\clients\client1 
     /app1 => c:\inetpub\applications\app1\current 
     /app2 => c:\inetpub\applications\app2\current 
     /app3 => c:\inetpub\applications\app3\current 
    /client2 => c:\inetpub\clients\client2 
     /app1 => c:\inetpub\applications\app1\current 
     /app2 => c:\inetpub\applications\app2\current 
     /app3 => c:\inetpub\applications\app3\current

'當前'目錄是一個符號鏈接到當前正在使用的版本。

這種設置有一定的優勢

.NET會話，應用程序和認證信息的自動隔離。任何交叉應用程序污染或安全問題（例如，客戶端1更改URL以查看客戶端2）的機率爲零。
自動web.config繼承，因此不需要在磁盤上搜索每個客戶端的配置文件。設置「只是工作」。
每個客戶端都可以（並且被配置）擁有自己的應用程序池，因此一個客戶端不會爲其他人在性能方面造成問題。

缺點：

有顯著內存開銷與具有每個客戶端
每個應用程序實例（例如/客戶端1/APP1，/客戶端1/APP2，/客戶機程序/程序app1，一個應用程序池。 ..）由ASP.NET單獨編譯，即使只有三個「真實」應用程序
有應用程序池預熱時間開銷。如果一個客戶端在一段時間內沒有訪問服務器，那麼第一個命中必須等待他們的工作進程啓動。我通過以32位模式運行所有池來緩解這種情況。

我最大的問題是內存消耗。如果我使用curl循環並在每個客戶端上擊中每個應用程序，則每個工作進程都使用大約100 MB的RAM。這意味着我需要16 GB的服務器RAM才能安全運行。考慮到這些應用程序本身並不那麼龐大或者非常複雜，這是非常糟糕的。每個工作進程的內存崩潰大致爲：專用字節70 MB，工作集85 MB，WS共享：32 MB。內存是一個問題，因爲這些是雲服務器，其成本與RAM使用率直接相關。即使這不是成本，但讓內存像這樣被浪費似乎仍然是不可能的。

我的第一個問題是：我能做些什麼來配置IIS或ASP.NET，以便不單獨編譯每個應用程序實例，而是意識到這三個應用程序實際上是完全相同的代碼，因此有望減少啓動時間並甚至可能是內存使用？如果我做客戶*應用程序*兩臺服務器，那就是在磁盤上編譯的720'應用程序'。

第二個問題是最佳實踐之一。我的設置是否正確（缺乏一個更好的詞）？爲了代碼的簡單性和安全性，內存浪費是否值得？是否有另一種方式來實現網絡的好處。配置繼承和會話/應用程序/表單身份驗證沒有這種方式單獨的應用程序？

考慮更改設置所需的代碼更改，因此只有三個應用程序，並且讓這些應用程序變得客戶端感知是相當艱鉅和嚴重的。

加入{客戶}每個MVC路由的根（一個應用程序是不MVC使得會是不同的）
利用{客戶}來搜索在磁盤上存儲在別處用於和負載配置文件。也許在json格式或什麼的。
對每個請求，確保{客戶端}沒有更改，如果有，請清除所有會話和應用程序變量。取消授權用戶以防止安全問題。

我不是在尋找任何人來爲我打定主意，但如果有人以前遇到過類似的問題，很高興聽到他們的消息。或者也許會有共識，我完全在錯誤的軌道上，需要改變我的代碼和設置。我認爲對這些問題的任何形式的反饋都是有用的，當然也值得讚賞。

來源

2012-04-11 mroach

我不認爲這個問題有一個簡單的答案，除非您將整個應用程序重寫爲單實例多租戶應用程序。那麼您還需要與客戶處理業務和現有的服務級別協議。由於安全問題，部分客戶不喜歡與其他客戶共享應用程序池或數據庫。我建議先審查你的服務級別協議，你可能會發現你確實需要保持這種方式。 – airmanx86 2012-04-11 10:02:12

順便說一句，您可能通過將任何共享代碼或整個Web應用程序簽名爲程序集，將其打包爲一個msi文件，然後將其安裝到服務器的GAC中，從而可以簡化編譯過程。 – airmanx86 2012-04-11 10:04:43

不知何故，我在我的職業生涯中已經做到了這一點，即使我已經做了多年，也不知道「多用戶」這個術語。現在我至少有一個很好的術語來搜索網絡。謝謝！現在我知道要尋找什麼，顯然我不是唯一有此問題的人。這有一些舒適。 – mroach 2012-04-11 11:26:02

謝謝@ airmanx86指出我正確的方向與多租戶。

我發現在這個過程中非常有用以下兩個博客文章：

http://blogs.planetcloud.co.uk/mygreatdiscovery/post/Simple-approach-to-multi-tenancy-in-ASPNET-MVC.aspx

http://blogs.planetcloud.co.uk/mygreatdiscovery/post/Simple-approach-to-multi-tenancy-in-ASPNET-MVC-Part-2.aspx

花了艱苦的工作了幾天真正理解這一點，並把它設置和修改我的代碼更加靈活，但結果令人驚歎。之前，如果我使用捲曲循環爲每個客戶端打了一個非常簡單的「調試」頁面，那麼啓動時間有幾秒鐘，大約100 MB的內存使用量，在我打所有客戶端時，首先要有被裝載的內存被換出。

現在，我運行相同的捲曲循環，幾乎可以瞬間打開100多個應用程序，並且我的工作進程內存使用率大約爲150 MB。我很高興！

現在該讓我運行而不是走路，將其餘的應用程序轉換爲真正的多租戶。

來源

2012-04-12 18:50:00 mroach

這兩篇博文都是一樣的 - 我很想知道對方應該是什麼人！哦，你的意思是第1部分和第2部分？ – 2012-08-03 11:07:09

使用共享ASP.NET應用程序減少IIS設置中的內存開銷

回答

相關問題