我不太清楚有關IIS的生命週期，但我一般的理解是：爲什麼IIS會在一段時間後停止？
我能得到更多推理以解釋爲什麼會發生這些行爲嗎？特別是關於項目＃2 ...我的服務器運行內部調度行爲，昨晚徹底死亡。原因是Application_End發生並且沒有客戶請求再次啓動IIS服務器。這似乎很奇怪。爲什麼不只是清理內存泄漏等，然後讓IIS保持原樣運行？我能想到的唯一原因是它可以讓服務器回收IIS使用的內存/ CPU，但這看起來毫無意義，也是錯誤的原因，比如我的調度程序問題！
我認爲其他海報已經很好地回答了您的主要問題，但我想解決您的問題的最後部分。
爲什麼不只是清理內存泄漏等，然後保持IIS運行的原樣？我能想到的唯一原因是它可以讓服務器回收IIS使用的內存/ CPU，但這看起來毫無意義，也是錯誤的原因，比如我的調度程序問題！
和
爲什麼我需要等待一個網頁請求，開始了我的游泳池，而不是具有服務器自動接收關於客戶端Web請求運行和賣力的？
讓我們考慮以下情況，以及如果IIS以這種方式行事將會發生什麼情況。如果我們有一臺託管數千個網站的機器（即您典型的共享託管環境），則每個網站都有自己的應用程序池（w3p.exe）。假設IIS爲每個網站啓動了一個工作池，無論是否有對該網站的請求，您都會有幾千個進程立即啓動，每個進程在每個空閒時間內啓動，比如2MB的RAM。如果你有2000個網站，你剛剛分配了4GB的內存，基本上什麼都不做，操作系統可能會開始進入頁面文件而不需要任何實際的需求。
這是可取的嗎？我想你會同意答案是否定的。
Tx，這是失蹤的一塊！對於共享環境而言，這比我自己的專用機器更有意義。 – 2011-01-30 03:03:35
可以通過更改網站的應用程序池回收設置來控制這些行爲。我們的生產網站每天凌晨3點在工作臺上回收游泳池，但我們的質量保證環境每天都會回收數次。
IIS中的每個網站都位於應用程序池中，並且您有三個不同的部分，這些部分影響應用程序池何時回收其工作進程;回收，性能和健康。當進程回收時，首先會創建一個新的工作進程（w3p.exe）來處理任何新的請求。舊的流程之前，任何現有的請求都會完成，然後關閉。 Application_Start和Application_End將在每個進程上運行，以便您可以適當地設置和拆卸資源。
Recycling settings對工作進程何時回收有最直接的影響，您可以選擇在運行特定分鐘數，處理請求數或每天特定時間後重新啓動。在使用特定時間的網絡農場中，可以確保您不會同時在農場中回收所有服務器。您可以關閉所有這些，以便您的工作進程不會回收，但正如您在問題中所述，這會使服務器容易受內存泄漏和線程掛起的影響，從而導致IIS無法爲該應用程序池中的網站提供任何請求。
如果Performance settings處於閒置狀態達指定的分鐘數或者CPU達到指定閾值，則可以關閉工作進程。您還可以增加應用程序池的工作進程數量並創建Web園。
Health settings監視員工作進程，如果他們反覆失敗並將檢查他們在指定時間內啓動和停止，它們將關閉。
從技術上講，IIS不會停止或重置。這是正在回收的應用程序池，它確保您的Web應用程序運行所在的應用程序域不會因爲代碼中的錯誤/低效率，框架中的錯誤等而長時間停滯。
IIS模型是實際上對於長時間運行的應用程序的健康非常有益。 Windows服務例如沒有得到這些好處。如果進程崩潰，就完成了。但是，由於IIS可以測量Web應用程序的各個方面，如響應時間，內存消耗，不活動等，它可以在某些情況下提供重置應用程序的功能。它們都是可配置的，但您應該始終努力開發Web應用程序，使得一個請求不依賴於事先請求。
您也不應該依賴Web應用程序中不直接響應Web請求的事情。因此，如果您啓動後臺線程來完成一些後臺任務，那麼我建議將其移入單獨的進程（例如Windows服務或計劃任務）。雖然如果您真的不想這樣做，那麼是一個IIS 7 Application Warm-Up Module，它會定期ping您的web應用程序以啓動它。
如果您正在使用進程內會話狀態並且重置導致問題，您可能需要考慮使用基於SQL的會話狀態提供程序。
無論如何，您可以在這裏閱讀有關配置IIS 7應用程序池回收行爲的更多信息。 http://technet.microsoft.com/en-us/library/cc753179(WS.10).aspx
已經有很好的答案了。我還不清楚的一件事是爲什麼一旦重啓事件發生，IIS7就不能完全初始化自己。即。爲什麼我需要等待一個網頁請求來啓動我的池，而不是讓服務器自動運行，並接收客戶端的Web請求？ – 2011-01-30 02:27:45