我們在本篇中接着講述“工作進程回收機制”。
本篇文章的議題如下：
工作進程回收機制講解
基於時間的回收機制
基於請求數的回收機制
基於內存使用的回收機制
基於活動狀態的回收機制
系列文章：
構建高性能.NET應用之配置高可用IIS服務器-第一篇：IIS必須掌握的知識
構建高性能.NET應用之配置高可用IIS服務器-第二篇 IIS請求處理模型
構建高性能.NET應用之配置高可用IIS服務器-第三篇 IIS中三個核心組件的講解（上）
構建高性能.NET應用之配置高可用IIS服務器-第三篇 IIS中三個核心組件的講解（下）
基於請求數的回收機制
這種基於請求數量回收的機制非常的好理解：當我們的應用程序收到的請求數量達到了一個閥值之后，就開始對應用程序池中的工作進程使用的資源進行回收，設置的方法和之前講述的基於時間的基本類似，如圖：
其實很多的時候，引起這種回收機制的原因都是應用程序已經無法處理過多的請求，導致了請求處理失敗，而不得不開始運行這種回收機制。
基於內存使用的回收機制
應用程序池的回收是可以通過它所使用的內存來設置的，可以通過設置它已經使用的內存和它的虛擬內存兩個方面來決定何時進行回收，大致的情況如下圖：
我們使用基於內存的工作進程回收機制可以在一定的程度上面防止內存泄露或者內存過度分配的情況。同時，有一個需要清楚的的就是：很多的時候，我們的Web應用程序的性能在很大的程度上來依賴緩存，特別是在ASP.NET中使用它的緩存API的時候，我們要非常的清楚這些問題。
緩存數據空間的大小不是無限制的，它的大小是可以配置的，並且有可能出現這樣的一種情況：數據在前一秒緩存進入，下一秒在使用的時候緩存的數據就沒有了，可能就會導致“找不到對象“等問題，這個時候，原因就是設置的緩存空間大小已經達到了設置值，導致了工作進程回收，使得數據全部丟掉。更多的關於這個方面的講述，可以參看我的另外的一篇文章：使用緩存的9大誤區(上)
另外，設置基於內存使用的回收機制，可以讓回收機制“監控“內存的時候，防止之前所說的內存泄露等情況。
說了這么多，那么我們就來看看如何來設置基於內存的回收機制。
專用內存使用情況（Private bytes）
這個設置可以限制在一個工作進程被回收之前可以使用的專用的不共享的內存的大小。其實說到這里，估計有些朋友又開始不明白了，因為這已經涉及到了Window內存管理的一些知識，大家可以參看這篇文章：window內存管理知識普及 。
注：可以說Window內存，進程調度等知識都是性能優化過程中需要掌握的基礎，其實現在很多的開發人員是完全不懂這些東西，僅僅只是知道C#語法，然后使用基本的語法規程編程，如果真是這樣，技術很難提升到很高的層面。
在IIS6中，這個設置在應用程序“屬性“的“回收“選下卡中，被稱之為“最大使用的內存“，單位是Mb，如下：
在IIS7中就稱之為“專用內存”（其實也是內核模式可使用的內存數量），單位為Kb。
這個值的設置對ASP.NET應用中的緩存和Session使用至關重要。如果這個值設置的太小，同時我們的應用程序又是非常大的依賴緩存，那么，就會導致工作進程頻繁的被回收，很多的在進程中保存的數據就會丟失，后果可想而知。
在ASP.NET2.0以后，緩存機制通過使用緩存剪裁策略來避免工作進程回收。什么意思呢？
就是，緩存機制會根據一些策略（例如，最近最少使用算法等）來將緩存中的一些數據移除，將空閑的位置讓給別的數據，從而避免緩存空間使用過大，從而避免了內存的使用太多而達到回收的閥值。我們可以在web.config中使用privateBytesLimit設置來配置緩存裁剪的級別，如下：
下面我們就看看在默認的情況下，何時出現緩存剪裁的問題：
| 用戶模式內存大小 |
||
| <=2GB |
>2GB(32位的操作系統) |
>2GB(64位操作系統) |
| 60%*物理內存或者800Mb |
60%*物理內存或者800Mb |
60%*物理內存或者1TB |
上面的表格比較簡單，我這里只是稍微的講述一下（以用戶模式內存小於2GB為例子）：如果操作系統中進程的用戶模式的內存小於2GB，那么privateBytesLimit的值就會是：60%*物理內存（例如，我們配置的內存條的大小為4GB），如果配置的物理內存條的大小實太小了，例如1GB，那么此時60%*1GB=600Mb，此時privateBytesLimit就不會按照這個來設置值，而是直接取800Mb。
同時，除了設置privateBytesLimit的固定值之外，我們還可以按照比例來設置，使用percentagePhysicalMemoryUsedLimit來設置當內存使用多少之后就開始對緩存進程裁剪，這是一個動態的過程，它可以自行計算。另外，這個值也可以有效的減少.NET垃圾回收機制的運行，提升性能。
虛擬內存使用情況（Virtual bytes）
在這里，我就沒有必要介紹虛擬內存的概念了。關於虛擬內存的問題也是非常的難以診斷和發現的，虛擬內存的問題主要就是碎片的問題。
當進程在運行的時候，它是由一個最大的虛擬內存大小的，例如，在Win32的操作系統中，就是4GB，用戶模式與內核模式各是2GB（在沒有使用/3GP的情況下）。當進程中的程序需要內存的時候，虛擬內存管理器會去分配一個空間，久而久之就可能導致虛擬內存產生很多的碎片，導致后續的內存分配無法進行，而產生”Out Of Memory”的問題。
其實，我們也沒用非常好的辦法來避免這個問題，但是可以通過一些經驗來緩解，例如，我們可以設置當虛擬內存空間使用了70%的時候就啟動回收，同時，我們也可以通過監視Process/Virtual Bytes這個性能計速器來分析數據。
系列文章鏈接：
IIS負載均衡-Application Request Route詳解第一篇： ARR介紹
IIS負載均衡-Application Request Route詳解第二篇：創建與配置Server Farm
IIS負載均衡-Application Request Route詳解第三篇：使用ARR進行Http請求的負載均衡（上）
IIS負載均衡-Application Request Route詳解第三篇：使用ARR進行Http請求的負載均衡（下）
IIS負載均衡-Application Request Route詳解第四篇：使用ARR實現三層部署架構
負載均衡原理與實踐詳解 第三篇 服務器負載均衡的基本概念-網絡基礎
負載均衡原理與實踐詳解 第九篇 服務器負載均衡技術進階-會話保持（上）
負載均衡原理與實踐詳解 第十篇 服務器負載均衡技術進階-會話保持（中）
負載均衡原理與實踐詳解 第十一篇 服務器負載均衡技術進階-會話保持（下） 之：延遲綁定