IIS 應用程式池配置不當是導致網站「假死」、事件日誌記錄「進程關閉時間超過限制」的核心主因。本文整理經實戰驗證的優化方案，涵蓋回收機制、效能參數、健康檢測三大維度，助您構建高穩定、高併發的 IIS 環境。
一、回收機制優化：避開業務高峰期強制回收
路徑：IIS 管理器 → 應用程式池 → DefaultAppPool → 右鍵屬性 → 「回收」頁籤
| 設定項目 | 建議值 | 核心邏輯 |
|---|
| 回收工作進程（分鐘） | 1740 (29 小時) | 錯開固定週期，避免每日固定時間觸發回收衝擊業務；原預設 1740 分鐘即可，若業務極敏感可調大。 |
| 回收工作進程（請求數目） | 不勾選 | 請求數觸發回收具不確定性，高峰期易引發連線中斷。 |
| 特定時間回收 | 03:00 (維護窗口) | 安排在流量最低谷，確保回收不影響用戶體驗。 |
| 記憶體限制回收 | 全不勾選 (或設極大值：虛擬記憶體 350MB / 實體記憶體 200MB) | 防止記憶體尖峰誤觸發回收導致服務中斷；若必須啟用，閾值須遠大於正常工作集。 |
二、效能參數調優：平衡資源釋放與響應速度
路徑：「效能」頁籤
- 閒置超時：20 分鐘（勾選）。長時間無請求自動釋放工作進程，節省記憶體。
- Web 園（最大工作進程數）：1 (預設)。嚴禁修改為 >1，除非應用程式完全無狀態且經壓測驗證。多進程會導致 Session 遺失、檔案鎖衝突、後台無法登入等詭異問題。
- 請求佇列限制：10000（預設 4000 偏小）。高併發下防止「伺服器太忙 (503)」錯誤。
三、健康檢測與快速失敗保護：給進程關閉足夠緩衝時間
路徑：「健康狀態」頁籤
- 啟用 Ping：保持預設勾選，確保進程存活偵測。
- 快速失敗保護：建議不關閉，但放寬條件（如：5 分鐘內 50 次失敗才停用應用程式池）。完全關閉可能讓故障進程無限重啟拖垮伺服器。
- 啟動時間限制：90 秒（預設）。
- 關閉時間限制：180 秒 (關鍵！)。預設 90 秒常導致複雜應用（大量連線釋放、快取寫入磁碟）關閉超時，產生事件 ID 1013/1022 錯誤。延長至 180 秒可覆蓋 99% 場景。
優化後驗證清單
- 事件檢視器 → System/Application 無「Worker Process shutdown exceeded time limit」錯誤。
- 壓力測試 (JMeter/LoadRunner) 下連續 24 小時無 503、無假死、記憶體曲線平穩。
- 應用程式池平滑回收（03:00）後業務零感知。
核心原則：回收策略要「錯峰、寬容」，效能參數要「省資源、不犧牲響應」，健康檢測要「給時間、有底線」。
