在共享環境中IIS7中回收應用程序池的最佳設置是什麼？

enter image description here

2008-10-13 GrZeCh

作爲一個Hoster，你一定要回收內存&時間，潛在的請求限制和CPU。您希望對這些限制非常積極，但請確保將它們發佈給您的客戶。

Memory - 對於x86盒子，可能是768.對於x64，根據每臺服務器的主機數量，可以將其設置得更高。您只需要小心，並在內存問題上觀看應用程序池回收事件。

Time - 我們通常在早上1點回收利用，正或負（第一個站點1:01，第二個1:11，第三個1:21，因此您沒有同時進行全部回收）

Request limit - 35,000是IIS6的默認值，但是這個數字非常隨意，並且非常依賴於相關網站。對於小型使用場所，在獲得35k次請求之前，每晚的回收將會很長時間。

CPU - 95％/ 1分鐘限制/ KillW3WP，但請謹慎使用。我對此的理解是，如果CPU在此工作進程的1分鐘限制內達到95％+，則當Action設置爲KillW3WP時，工作進程將被終止並且無法在限制的其餘部分重新啓動。您可能最初想嘗試NoAction，並仔細查看您的活動日誌。

Recycle Event Logs - 您希望確保您爲每個設置的事件閾值記錄應用程序池回收 - 即，如果基於請求限制進行限制，請確保已啓用請求限制日誌記錄。

有一點要記住的是，你應該在<deployment>元素在你的machine.config設置retail="true"：

<system.web> 
    <!-- 
     <deployment 
      retail = "false" [true|false] 
     /> 
    --> 
    <deployment retail="true" /> 
</system.web>

不設置這將允許網站啓用調試，它允許無限超時的請求 - 不完全適合主機...

2008-10-14 16:08:02

提示：當您回收您的應用程序，你的所有會話變量被銷燬...所以小心這個！

恕我直言，保持默認值。

2008-10-13 18:43:10

但是，這只是如果你是InProc，不是嗎？ – 2012-11-29 19:37:55

如果您使用InProc，您的會話變量只會被銷燬。我會始終保持會話變量不受影響，以便您可以輕鬆擴展到Web花園/農場。 – 2013-07-25 10:31:00

如果您的網站流量很大，請使用長時間的回收計劃。如果流量較低的站點使用較短/默認的時間表來節省內存。

丹尼爾·S是正確的，你的會話變量被摧毀的循環，所以一定要測試這個好或有好的錯誤保護/恢復讓您的會話對象時，。

2008-10-13 18:56:04

您需要滿足您的需求，考慮您的網站/ Web應用程序的內存量和使用高峯時間。

還考慮到您的網站/ Web應用程序的內存使用情況，就好像有內存泄漏一樣，那麼您可能會更頻繁地回收，然後再考慮。

根據回收成本衡量任何泄漏，如上所述，您將失去狀態變量。

2011-12-20 11:44:14

回答