SharePoint Application Pool的推薦設定

Default Application pool

=========

別碰它, 確保沒有什麼使用它.

千萬不要刪掉它. 為什麼? 因為IIS不喜歡. 如果刪了它, IIS會發瘋的.

不要重新命名它.

• Performance application pool settings: 空閑十分鐘後, shutdown.
• Health Application pool settings: 關掉pinging, 關掉rapid failure.

Cantral Admin App Pool, SSP Admin App Pool

==========

• Recycling Application Pool Settings:
• 每晚上2:00AM 到4:00AM回收.
• 最大實體記憶體和最大虛擬記憶體, 這些App pool不會消耗多大記憶體, 想要多少就給多少吧. 如果需要限制, 那麼我會在一個典型的系統上限制為500MB. 如果你想要保守一點, 你可以限制它們為200MB. 它們真的不應該需要這麼多記憶體.
• Performance Application Pool Settings:
• 空閑十分鐘後就shutdown. 這些App pool不需要一直運行, 因為它們僅供管理之用的.
• 不用擔心CPU. 如果你真要限制的話, 就限制它為5%吧.
• Web Garden, 想都不要想. 你甚至都不希望一個w3wp.exe的已耗用時間太長.
• 如果你真的很想省記憶體, 你應該讓central 和 ssp共用一個app pool. 基於安全的考慮, 如果你有兩個團隊管理ssp 和central的話, 那就不要改為共用了.
• Health Application Pool Settings:
• Pinging: 關掉.
• Rapid failure: uncheck掉.
• Startup/Shutdown: 你不會希望看到因為他們啟動或者停止時因為慢了一點而報出錯誤的, 推薦它們兩項限制修改為300。
• Identify Application Pool Settings:
• 使用單獨的帳號. 如果出現問題, 這裡是首先應該檢查的地方.

SharePoint App Pool or %Your Content App Pool% (Whatever you call it)

===========

• Recycling Application Pool Settings:
• 關掉按分鐘回收.
• 每晚上2:00AM 到4:00AM回收.
• 最大的物理和虛擬記憶體: 這個配置需要很多的控制. 這個部分是用來在消耗了太多記憶體的時候回收Application Pool時使用的. 在實體記憶體上, 32位的系統上App Pool資料不是很多的時候, 一般限制在800MB到1200MB之間. 如果一共有2G記憶體, 那麼至多也就是限制為800MB了. 如果是4G記憶體, 那就限制為1000MB或至多1200MB. 如果是在64位的前端, 一共擁有8到16G記憶體的話, 我聽說有限制為2G的, 甚至不予限制的.
• Performance Application Pool Settings:
• Idle timeout, 關閉. 除非App Pool不經常使用, 不要開啟這個選項.
• Request queue, 不要選.
• CPU限制, 不要選. 這些web app pool正是你想要使用cpu的地方.
• Web Garden, 不要使用.
• Health Application Pool Settings:
• Pinging: 保持開啟. 你可以每隔10-15分鐘ping它一下, 讓它保持運轉
• Rapid failure: 不要勾選, 除非你只有一個web application在使用這個app pool, 並且所有的內容都在這個app pool上.
• Startup/Shutdown: 你不會希望看到因為他們啟動或者停止時因為慢了一點而報出錯誤的, 推薦它們兩項限制修改為300到900。
• Identify Application Pool Settings:
• 使用單獨的帳號. 如果出現問題, 這裡是首先應該檢查的地方.

關於web garden, MSDN解釋到:

因為web garden開啟了允許使用多個進程, 所以每個進程都會有自己的一份application state, in-process session state, caches, static data的拷貝. 所有的應用程式都不應該使用web garden, 特別是他們需要維護state的時候. 請確保在決定web garden模式是否合適前, 先對效能進行衡量.

 

當使用web garden時, 理解session state和round robin的運行機制很重要. 理解其他的application 配置如何影響應用程式也很重要的.

 

我的經驗是, 使用多出來的一個worker process的話, 我可以讓一個web application的效能更好一點. 但是排查錯誤就非常困難, 而且進程隔離也很困難. 開發人員也不喜歡這樣用. 在我下結論永遠不要使用web garden之前, 請先按照上面的推薦進行配置. 如果你想提高效能, 先測一個work process的, 再測兩個的. 如果沒有提高, 就不要用.

 

摘譯自:

Recommendations for SharePoint Application Pool Settings

http://blogs.msdn.com/b/joelo/archive/2007/10/29/sharepoint-app-pool-settings.aspx