b.請求數(shù)目
       這個要看具體的情況了。如果只有10個請求，可是有5個都在請求那個比較占資源的頁面（可能是統(tǒng)計年度報表之類），這個時候就會出現(xiàn)進程當?shù)舻那闆r，如果請求有1000個可是一個也沒運行比較占資源的頁面，這個時候進程肯定是很正常的，所以根據(jù)請求的數(shù)目來決定也不一定符合實際需要。

      c.計劃的時間
       這個其實很好，不過具體什么時間回收好呢？通常我們都是設(shè)置在凌晨兩三點鐘，這個時候回收是有必要的，不過針對出現(xiàn)隨時可能出現(xiàn)是高內(nèi)存占用并不是很適用。

      d.內(nèi)存（虛擬內(nèi)存或已使用的內(nèi)存）
       這個針對出現(xiàn)內(nèi)存問題引起的進程當?shù)魧嵲谔线m了，不過設(shè)置多大的值比較好是一個很重要的問題，值不能太小了，否則如果訪問量都很大超過這個值的時候也會自動回收，這個就很沒必要了。一定要多多觀察進程的實際占用情況再做決定。

       IIS應用程序池自動回收機制給我們帶來便利的同時，也會造成潛在的問題。編寫依賴于Global文件中全局事件的函數(shù)時我們要特別注意了，尤其是每天定時執(zhí)行的函數(shù)，因為重新啟動IIS應用程序池后，如果沒有用戶訪問網(wǎng)站，則無法激活Application_Start事件，函數(shù)也就無法執(zhí)行了。