IIS 6.0 應用了新的進程模型。核心模式的HTTP偵聽程式（Http.sys）接收並發送HTTP請求（甚至可以使用它的響應緩衝來滿足請求）。背景工作處理序註冊URL子空間，Http.sys將請求發送到相應的進程（如果使用應用程式集區，則發送到進程集合）。
圖 4 展示了IIS 5.0和IIS 6.0進程模型之間的差異。IIS 5.0使用WinSock在連接埠80接受串連。請求由 inetinfo 進程負責接收，然後或者在進程內執行請求，或者將它交給dllhost 進程在進程外進行處理（為了達到隔離的目的）。響應則由 inetinfo 進程發送回去。圖 4 IIS 5.0 和 IIS 6.0 的進程模型IIS 6.0 進程依賴於核心模式的Web驅動程式Http.sys。在新的模型中，Http.sys負責管理串連和處理請求。請求可能通過Http.sys緩衝得到滿 足，也可能被交給一個背景工作處理序以便得到進一步處理（見圖5）。可以配置多個背景工作處理序，從而以較低開銷實現了隔離。Http.sys包括了一個響應緩衝。當請求與響應緩衝中的某個條目相匹配的時候，Http.sys直接從核心模式中發送緩衝響應。圖5展示了請求通過Http.sys得到處理的情況（請求也可能向上交給某個背景工作處理序進行處理）。圖 5 IIS 6.0中的請求處理由於Web伺服器既包括核心模式的組件，也包括使用者模式的組件，必須對二者同時進行調整才能獲得最佳效能。因此，針對特定負載的IIS 6.0調整工作需要對如下內容進行配置：· Http.sys（核心模式驅動程式）以及相關的核心模式緩衝。· 背景工作處理序和使用者模式IIS，包括應用程式集區配置。此外，我們還將在後文中討論會對效能造成影響的其他參數。
核心模式的調整與效能有關的Http.sys設定可以劃分為兩類：緩衝管理以及串連和要求管理。所有的註冊表設定都儲存在以下條目中：HKEY_LOCAL_MACHINE/System/CurrentControlSet/Services/Http/Parameters如果HTTP服務正在運行，必須首先停止服務，然後重新啟動電腦，以便讓設定生效。
緩衝管理設定Http.sys具有的優點之一便是核心模式緩衝。如果響應位於核心緩衝中，那麼可能可以完全通過核心模式來滿足某個HTTP請求，這顯然可以極大降低CPU處理請求的開銷。但是，IIS 6.0的核心模式緩衝是一種基於實體記憶體的緩衝，每個條目都需要佔用一定的記憶體空間。緩 存中的條目只有在被使用的時候才能提供益處。但是，條目在任何時候都會佔用實體記憶體，不論它是否被使用。所以，需要對緩衝某個項目帶來的益處（能夠直接從 緩衝中滿足請求）以及它在整個生命期中的開銷（需要佔用實體記憶體）進行評估，並且考慮可用資源（CPU、實體記憶體）和工作負載的情況。Http.sys 試圖僅在緩衝中儲存有用（經常被訪問）的項目，但是，如果針對特定工作負載來調整Http.sys緩衝，Web伺服器的效能還可以獲得一定程度的提高。以下是一些有用的Http.sys核心模式緩衝設定：· UriEnableCache. 預設值：1。設為非零值可以啟用核心模式響應和分段緩衝。對於大多數工作負載，緩衝都應該保持啟用。如果希望獲得超低響應和較低的緩衝利用率，那麼請考慮禁用緩衝。· UriMaxCacheMegabyteCount. 預設值：0。設為非零值可以指定核心緩衝可以使用的最大記憶體數量。預設值為0，允許系統自動調節緩衝能夠使用的記憶體數量。注意：只能設定可以使用的最大記憶體數量，而且系統可能不允許緩衝增長到指定的大小。· UriMaxUriBytes. 預設值：262144 位元組（256 KB）。本參數設定了核心緩衝中每個條目的最大長度。大於這個長度的響應或分段都不會被緩衝。如果有足夠的資金，可以考慮增加此參數的值。如果資金有限，而且大型的條目會擠掉較小的條目，那麼可以將本參數設為更小的值。· UriScavengerPeriod. 默 認值：120秒。一個“清道夫”程式會定期掃描Http.sys緩衝，在兩次掃描期間沒有被訪問過的條目將被刪除。可以將掃描周期設定為一個較高的值，以 減少掃描次數。但是，如果訪問頻率低的老條目仍然保留在緩衝中，緩衝佔用的記憶體將不斷增加。如果將此期限設定得過低，掃描頻率會過於頻繁，而且可能導致緩 存的過度清洗和擾動。
請求和串連管理設定此 外，Http.sys管理入站HTTP/HTTPS 串連，並且是在這些串連上處理請求的第一個層。它使用內部資料結構儲存有關串連和請求的資訊。雖然這樣的資料結構可以按需建立（或釋放），但如果在 look-aside裡表中儲存部分資料結構留作備用，則可以實現更高的 CPU 效率。儲存這樣的儲備有助於Http.sys利用更少的CPU資源來處理負載波動。注意：負載波動不一定由外部的負載波動而引起。一些旨在改善批處理或者 中斷調解的內部最佳化措施也可能導致負載波動和起伏。儲備有助於減少CPU的使用率和縮短延遲時間，同時能夠增加Web伺服器的處理能力，但是也會增加記憶體的使用率。在調整Http.sys的請求和串連管理行為的時候，需要牢記的因素便是：可用的伺服器資源，效能目標以及工作負載的特性。您可以使用以下請求和串連管理設定：· MaxConnections。 本 設定用來控制Http.sys所允許的並發串連的數量。每一個串連都會耗用非分頁池（一種寶貴和有限的資源）。預設值的設定相當保守，以限制串連佔用的非 分頁池數量。對於配備了充足記憶體的專用Web伺服器，如果預計會產生大量的並發串連，可以將此值設定得更高一些。此值設定得越大，佔用的非分頁池就越多， 所以要務必小心，應該使用一個與系統配置相適應的正確數值。· IdleConnectionsHighMark、IdleConnectionsLowMark和IdleListTrimmerPeriod. 這些值用來控制對非並行使用的串連結構的處理：在某個時間必須提供多少可用的串連（用於處理串連負載的波動）、釋放列表的上下界限、以及串連結構剪下和補充的頻率等。· RequestBufferLookasideDepth 和 InternalRequestLookasideDepth 這些值控制與緩衝區管理有關的資料結構的處理工作，以及應該完成多少儲備以應付負載波動情況。
使用者模式設定
IIS 註冊表設定以下註冊表設定可以在下面的條目下找到：HKLM/System/CurrentControlSet/Services/Inetinfo/Parameters/· MaxCachedFileSize（REG_DWORD），以位元組為單位。決定了能夠被緩衝的檔案大小（預設為256 KB）。實際值根據資料表中最大檔案的數量和大小以及可用的RAM數量而定。對頻繁訪問的大型檔案進行緩衝可以降低CPU使用率，減少磁碟訪問以及相關的延遲時間。· MemCacheSize（REG_DWORD）， 以MB為單位。將IIS使用者模式緩衝限制為指定的大小（預設設定為根據可用記憶體的數量由IIS調整緩衝的大小）。根據“熱門”檔案集合（頻繁訪問檔案的集 合）的大小以及RAM數量或者IIS進程地址空間（正常情況下應該在2GB以下），需要認真選擇本參數的值。· DisableMemoryCache（REG_DWORD）。如果設定為1（預設為0），則禁用使用者模式的IIS緩衝。在快取命中率非常小的時候，可以完全禁用緩衝，以避免與緩衝代碼路徑有關的開銷。· MaxPoolThreads（REG_DWORD）。設定每個處理器能建立的池線程的最大數量（預設為4，範圍不限。）每一個池線程都觀察網路請求，然後處理它們。MaxPoolThreads 計數沒有包括當前處理ISAPI應用程式的線程。如果CPU的平均使用率沒有處於最佳狀態，應該增加本參數的值，因為現有的所有線程都為繁忙狀態，沒有用於處理新請求的可用線程。· PoolThreadLimit（REG_DWORD）。設定系統能建立的池線程的最大數量（預設值為處理器數量的4倍，範圍不限）。PoolThreadLimit 必須大於或等於MaxPoolThreads。正常情況下，PoolThreadLimit = MaxPoolThreads ´ 處理器數量。僅僅設定其中的一個參數是不夠的。如果同時指定了MaxPoolThreads 和PoolThreadLimit參數，則可以施加更嚴格的限制。· ObjectCacheTTL（REG_DWORD）， 以秒為單位。控制沒有被訪問過的對象在IIS使用者模式緩衝中停留的時間長度（預設值為30秒，如設定為0xFFFFFFFF則禁用對象緩衝清道夫線程）。 如果系統配備了足夠的記憶體，而且提交的內容不經常變化，那麼可以增加本參數的值。如果系統記憶體不足而且使用者模式緩衝的大小在不斷增長，則應該降低本參數。 請參閱本節下面的 ActivityPeriod 部分。· ActivityPeriod（REG_DWORD）， 以秒為單位。只有當檔案在活動期限（預設為10秒鐘，如果設為0則禁用本選項）內被重複命中，才允許快取檔案。本參數會降低由於緩衝不經常訪問的檔案而引 起的緩衝開銷，如果緩衝內容變化不大，而且沒有足夠的可用記憶體，那麼可以增加活動期限的值；或者，如果緩衝上存在大量請求負載，可以降低活動期限的值。· DataSetCacheSize（REG_DWORD）預設值為50。設定設定資料庫資料集緩衝中虛擬目錄條目的最大數量。如果已經安裝的虛擬目錄的數量超過了預設值，可以增加本參數的值。在提交靜態內容的時候，一個容量不足的資料集緩衝會增加延遲時間（更低的輸送量和更低的CPU使用率）。
IIS Metabase以下設定可以在 W3SVC/ 下找到。· AspMaxDiskTemplateCacheFiles。啟用ASP指令碼模板的磁碟緩衝。ASP模板的編譯是一件非常耗費處理器資源的工作。記憶體大小限制了可以緩衝在記憶體中的模板的數量。從磁碟上的模板緩衝中取回編譯後的模板所需的開銷比編譯ASP記憶體緩衝中沒有的模板要小。請參見下文中的 AspScriptEngineCacheMax 一節。· AspDiskTemplateCacheDirectory。如果可能，可以將其設定為不頻繁使用的磁碟（例如，沒有和作業系統、分頁檔案、IIS日誌或者其他頻繁訪問的內容共用的磁碟）。預設目錄是 “%windir%/system32/inetsrv/Template Disk cache/ASP Compiled Templates”。· AspScriptEngineCacheMax。將其設定為記憶體容量所允許的最大的指令碼引擎數（預設為125）。· AspScriptFileCacheSize。設定為記憶體容量所允許的最大的ASP模板數量（預設250）。請參閱前文中的AspMaxDiskTemplateCacheFiles一節。· AspExecuteInMTA。 如果在交付某些ASP內容時希望對出現的錯誤或故障進行檢測，請將本參數設定為1（啟用）。例如，如果需要託管多個網站，而且每個網站都運行在它自己的工 作進程之下，那麼便可以啟用本參數。錯誤一般可以在事件檢視器中的COM+部分中看到。本設定啟用了ASP中的多執行緒 Apartment模型（預設值為0，表示禁用）。· AspProcessorThreadMax。如果當前設定（預設為25）不足以滿足負載的需求（可能會導致某些請求出現錯誤），可以增加本參數的值。· CentralBinaryLoggingEnabled。通過將本參數設定為TRUE，可以啟用集中的二進位日誌記錄。二進位IIS日誌記錄可以減少對CPU的使用，降低佔用的磁碟空間以及減少磁碟I/O操作。集中的二進位日誌可以被導向一個二進位檔案，而無論託管網站的數量如何。分析二進位格式的日誌需要一個後處理工具。
IIS 背景工作處理序選項（IIS Admin UI、應用程式集區屬性）在 沒有管理員幹預、服務重啟或者電腦重啟的情況下，IIS管理介面上的IIS背景工作處理序回收選項為發生的緊急故障或事件提供了有效解決辦法。這樣的情況包 括記憶體流失，泄漏會增加記憶體負擔，或者導致背景工作處理序進入不響應或空閑狀態。在正常情況下，可能不需要啟用回收選項，所以可以關閉它（或者對系統進行配置， 以很低的頻率執行回收工作）。在下面的章節中，黑體字名稱是per-app-pool（應用程式集區）變數。在使用指令碼設定這些變數的時候，可以使用路徑“ /LM/W3SVC/AppPools/n”，在這裡n 代表應用程式集區索引。有三個選項，如下表所示：· 回收選項。可以在“回收”選項卡中找到。· 效能選項。 可以在“效能”選項卡中找到。· 背景工作處理序健康監視選項。可以在“健康”選項卡中找到。表 8. 回收選項
| 參數 |
描述 |
| PeriodicRestartRequests，DWORD，選項預設為禁用，預設值為35000 |
按照時間定期回收 |
| PeriodicRestartRequests，DWORD，選項預設為禁用，預設值為35000 |
根據請求的（累計）數量定期回收 |
| PeriodicRestartSchedule， MULTISZ，預設為禁用，預設為空白字串值 |
在指定的時間進行回收 |
| · PeriodicRestartMemory， DWORD，預設值為512 MB· PeriodicRestartPrivateMemory， DWORD，預設值為192 MB |
如果達到了以下兩個條件之一，基於記憶體的回收（預設為禁用）將允許回收背景工作處理序：· 虛擬記憶體的最大容量· 已使用記憶體的最大容量如果面臨不斷增長的記憶體容量壓力，可以其中一個參數或全部參數，基於嚴格的記憶體容量標準，頻繁回收背景工作處理序，以緩解記憶體壓力。 |
表 9. 效能選項
| 參數 |
描述 |
| IdleTimeout，DWORD，以分鐘為單位，預設值為20 |
在進程的空閑時間超過指定的時間時，關閉背景工作處理序。這樣可以節省有限的記憶體資源，但是如果CPU負載繁重，需要頻繁啟動新的背景工作處理序，則不建議採取這種做法，因為建立進程會帶來一定的開銷。 |
| AppPoolQueueLength，DWORD，預設值為2000 |
限制每個應用程式集區（App-Pool）的核心請求隊列的長度。請求會消耗分頁池，在對分頁池具有大量需求的情況下，應該降低本參數的值。如果超過指定的長度，會導致伺服器拒絕請求，併產生編號為503的非自訂錯誤。 |
| CpuAccounting，BOOLEAN，預設為禁用（0），啟用為1 |
監 視CPU的使用方式。您可以按照百分比設定CPU的最大使用率（CpuLimit，DWORD，預設值為0）和監視工作的重新整理周期 （CpuResetInterval，DWORD，預設值為0，以分鐘計）。如果達到了CPU的使用率限制，或者不採取任何操作（但是會在事件記錄中寫入 一個事件），或者關閉背景工作處理序（CPUAction，DWORD，預設值為0，表示“不採取任何操作”；最大值為1，表示“關閉背景工作處理序”）。 |
| MaxProcesses，預設：使用1個背景工作處理序處理所有請求 |
可 以在操作的Web Garden（Web園）模式中控制背景工作處理序的總數量。在Web Garden模式中，幾個背景工作處理序負責處理單個應用程式集區下的請求負載。沒有通過不同的應用程式集區為Web網站預先分配任何背景工作處理序。在某些情況下，一個 背景工作處理序無法滿足負載的處理需要（可以通過糟糕的CPU使用率和漫長的回應時間看出這一點），增加背景工作處理序的數量則有助於改善系統的輸送量和CPU使用 率。在託管了多個網站的情況下，可以考慮採用Web Garden模式。此外，在其中一個進程突然崩潰的情況下，採用多個背景工作處理序還提供了更多可靠性，而且幾乎不會出現所有服務均中斷的情況。與預先分配應用 程式池相比，Web Garden模式更容易設定和控制。 |
表10. 健康選項
| 參數 |
|
描述 |
|
| PingingEnabled，BOOLEAN， 預設值為1PingInterval，DWORD，預設值為30秒 |
|
以固定時間間隔（PingInterval）Ping 背景工作處理序（PingingEnabled）。如果沒有響應，則認為背景工作處理序發生錯誤，IIS將試圖終止進程併產生一個新的進程。 |
|
| RapidFailProtection，BOOLEAN，預設RapidFailProtectionMaxCrashes， DWORD，預設為5個故障RapidFailProtectionInterval， DWORD，預設為5分鐘 |
|
設 置在給定的時間段內（RapidFailProtectionInterval）允許產生的最大故障數量 （RapidFailProtection-MaxCrashes），對不斷快速產生故障的情況加以控制（RapidFailProtection）。如果 到達了指定了故障率，應用程式集區將被禁用，並且在事件記錄中寫入相關資訊。 |
|
| StartupTimeLimit，DWORD，預設為90秒 |
|
控制背景工作處理序的啟動時間，超過此時間，則認為其發生了故障。 |
|
| ShutdownTimeLimit，DWORD，預設為90秒 |
|
控制背景工作處理序的關閉時間，超過了此時間，則認為其處於不響應狀態。 |
|
安全通訊端層的調整參數安全通訊端層（Secure Sockets Layer，SSL）的使用會加重CPU的負擔。SSL中最為耗費資源的部分為建立會話所需的開銷（包括一次完整的握手），然後是重新串連的開銷和加密/解密的開銷。為了獲得更好的SSL效能，請執行如下操作：· 啟用SSL會話的“保持活動”（keep-alive）特性。這樣可以消除建立會話所需的開銷。· 如果可能，重新使用會話（特別是對於那些沒有“保持活動”的流量）。· 注意：密鑰越長，安全性就越高，但是需要的CPU時間就越多。· 注意：並不是所有的頁面組件都需要加密。但是，混合的純文字HTTP和HTTPS可能會導致用戶端瀏覽器彈出一個警告，告知並不是所有的頁面內容都得到了保護。
ISAPI 對於ISAPI，沒有任何具體的調整參數。如果編寫一個私人的ISAPI擴充，請確保代碼在執行和資源使用方面具有高效率。請參閱後文中的 影響IIS效能的其他問題。
Managed 程式碼調整參數· 確信已經預先編譯了所有的指令碼。可以在每個目錄中調用一個.NET指令碼來完成這項工作。在編譯完成之後，需要複位IIS。在修改了Machine.config、 Web.config或任何.aspx指令碼之後需要重新編譯。· 如果不需要工作階段狀態資訊，請確信在每個頁面中關閉了此項目。· 當使用者在隔離模式（每個網站一個應用程式集區）下運行包含ASP.NET指令碼的多個主機的時候，應該監視記憶體使用量情況。請根據預計將要並發啟動並執行應用程式集區 的數量，為IIS伺服器配備足夠的記憶體。考慮在存在多個隔離進程的地方使用多個應用程式定義域（app-domains）。
影響IIS效能的其他問題· 安裝沒有緩衝意識的過濾器。安裝沒有HTTP緩衝意識的過濾器會導致IIS禁用全部緩衝，從而造成效能急劇下降。老的ISAPI過濾器（在IIS 6.0之前編寫的過濾器）可能會存在這個問題。可以使用HTTP緩衝的過濾器在設定資料庫中被標記為“具有緩衝意識”的過濾器。· CGI 請求。出於效能的考慮，我們不建議使用CGI應用程式處理請求。由於需要頻繁建立（和刪除）CGI進程，會產生大量的系統開銷。更好的替代辦法是使用ISAPI程式和ASP（或ASP.NET）指令碼。這些方式都可以使用隔離。
NTFS 檔案系統設定HKLM/System/CurrentControlSet/Control/FileSystem/ 下的 NtfsDisableLastAccessUpdate （REG_DWORD）1。通 過禁止更新最後一次訪問的檔案或目錄的日期和時間戳記，這個針對整個系統的切換參數會降低磁碟I/O負載和縮短延遲。預設情況下本鍵不存在，因此需要額外 添加。如果操作包含數千個目錄的大型資料集（或者大量主機），禁用更新的效果十分明顯。如果只需要保留資訊Web供Web管理使用，我們建議使用者使用 IIS日誌代替它。警告：某些應用程式（例如增量備份工具）需要使用這些更新資訊，如果沒有這些資訊，它們將無法正常工作。
IIS 6的應用程式集區屬性[ 2006-10-27 18:42:08 | Author: Ychon ] Font Size: Large | Medium | Small
回收
在回收標籤，你可以設定背景工作處理序的回收方式：
回收背景工作處理序（分鐘）：在背景工作處理序運行多少分鐘後回收背景工作處理序，預設啟用，並且設定為1740分鐘（29小時）；
回收背景工作處理序（請求數目）：在背景工作處理序處理多少 個HTTP請求後終止此背景工作處理序，預設禁用，如果啟用則預設值為35000；
在下列時間回收背景工作處理序：在指定的時間回收背景工作處理序，預設禁用；如需啟用，勾選後點擊添加按鈕添加回收的時間即可，使用24小時制定義回收的時間；
消耗太多記憶體時回收背景工作處理序：
最大虛擬記憶體（兆）：當背景工作處理序使用的虛擬記憶體達到設定的值時回收背景工作處理序，預設禁用，如果啟用則預設值為500 M；建議設定為不超過虛擬記憶體總數的70％；
最大使用的記憶體（兆）：當背景工作處理序使用的實體記憶體達到設定的值時回收背景工作處理序，預設禁用，如果啟用則預設值為192 M；建議設定為不超過實體記憶體總數的60％；
另外需要注意的是，應用程式集區具有以下兩種背景工作處理序回收方式，不過這兩種回收方式均不會造成Web服務的中斷：
預設情況下，應用程式集區使用重疊回收方式。在這種方式下，當應用程式集區要關閉某個背景工作處理序時，會先建立一個背景工作處理序，直到新的背景工作處理序成功建立後才關閉舊的背景工作處理序；
應用程式集區也可以先關閉舊的背景工作處理序，然後再建立新的背景工作處理序。
如果Web應用程式不支援多執行個體運行，那麼你必須配置應用程式集區禁止使用重疊回收方式。此配置無法在IIS管理主控台中進行修改，只能通過在metabase.xml中修改對應應用程式集區的DisallowOverlappingRotation metabase屬性為true進行。
效能
在效能標籤你可以設定背景工作處理序的運行方式：
在空閑此段時間後關閉背景工作處理序（分鐘）：當背景工作處理序空閑多少分鐘後關閉此背景工作處理序，這降低了空閑背景工作處理序對系統資源和CPU效能的消耗，預設啟用並且設定為20分鐘；
核心請求隊列限制為（請求次數）：當HTTP.sys接收到某個用戶端發送的HTTP請求時，如果處理此請求的對應應用程式集區的背景工作處理序還處於忙狀態，則HTTP.sys將接收到的請求儲存在對應應用程式集區的請求隊列中，直到背景工作處理序空閑為止。此選項即用於設定此應用程式集區的請求隊列所能容納的請求數量，預設情況下每個應用程式集區的請求隊列限制為保留1000個請求，如果超出則向用戶端返回503錯誤，你可以根據需要適當進行修改，最大可以設定為65535。但是如果設定太大則會消耗大量的系統資源 ，而設定太小會導致用戶端訪問時頻繁出現503錯誤。
啟用CPU監視：監視此應用程式集區的CPU使用率，預設未啟用；如果某個應用程式集區佔用的CPU利用率過多，那麼可以通過配置此選項來限制此應用程式集區；
最大CPU使用率（百分比）：所設定的應用程式集區所能使用的最大CPU使用率；啟用CPU監視時預設值為100；
重新整理CPU使用率（分鐘）：重新整理CPU使用率的間隔時間；啟用CPU監視時預設值為5；
CPU使用率超過最大使用率時執行的操作：當此應用程式集區的CPU使用率超過所設定的最大CPU使用率時所進行的操作，啟用CPU監視時預設為無，此時IIS只是在事件記錄中進行記錄而不進行其他動作；如果選擇為關閉，那麼IIS將關閉此應用程式集區中的所有背景工作處理序；
Web園：在Web園中你可以配置此應用程式集區所使用的最大背景工作處理序數，預設為1，最大可以設定為4000000； 配置使用多個背景工作處理序可以提高該應用程式集區處理請求的效能，但是在設定為使用多個背景工作處理序之前，請考慮以下兩點：
每一個背景工作處理序都會消耗系統資源和CPU佔用率；太多的背景工作處理序會導致系統資源和CPU利用率的急劇消耗；
每一個背景工作處理序都具有自己的狀態資料，如果Web應用程式依賴於背景工作處理序儲存狀態資料，那麼可能不支援使用多個背景工作處理序。
健全狀態
在健全狀態標籤你可以配置應用程式集區監視背景工作處理序的健全狀態，
啟用Ping：預設情況下應用程式集區配置為每隔30秒Ping背景工作處理序，當背景工作處理序沒有進行響應時，則認為此背景工作處理序出現故障並預設配置為關閉此背景工作處理序。你可以修改Ping的時間間隔，但是太長的Ping間隔可能會導致Web服務的中斷，而太短的Ping間隔又會消耗更多的系統資源和CPU利用率，因此建議你保留預設配置；
啟用快速失敗保護：如果Web應用程式代碼編寫有問題，它可能會導致背景工作處理序持續出現問題。預設情況下應用程式集區配置為啟用快速失敗保護，當背景工作處理序在配置的時間段（預設為5分鐘）內發生的失敗次數超過了配置的值（預設為5次），則禁用此應用程式集區。
啟動時間限制：IIS等待屬於此應用程式集區的背景工作處理序啟動的時間，當背景工作處理序啟用時間超出此設定值時，IIS會在事件記錄中進行記錄；
關閉時間限制：當IIS檢測到某個背景工作處理序出現故障時，將此背景工作處理序標記為關閉，此選項指定了IIS等待背景工作處理序自動關閉的時間限制，如果超出此時間限制後背景工作處理序尚未關閉，則IIS強行關閉背景工作處理序。
標識
在標識標籤，你可以配置背景工作處理序所啟動並執行使用者賬戶。在IIS 5或者當IIS 6運行在IIS 5隔離模式時，背景工作處理序運行在本地系統賬戶，而運行在背景工作處理序隔離模式下的IIS 6的背景工作處理序運行在網路服務賬戶下，這降低了系統被攻擊的可能性。
你可以配置背景工作處理序運行在預定義的本地系統、本地服務或網路服務賬戶下，也可以配置為使用某個自訂的使用者賬戶。建議使用預設的網路服務賬戶；不過如果為了更高的安全性，可以配置使用自訂的使用者賬戶，不過建議你只是將此自訂使用者加入到IIS_WPG使用者組中，因此IIS_WPG使用者組包含了可以啟動和運行背景工作處理序的最小許可權。
