提高 SharePoint 頁面通路速度之增加W3WP程序數及重置回收

上一篇文章中我們提到了IIS應用池的預加載功能，今天來講一下W3WP的程序數優化。

上文中我們提到了W3WP這個程序，這個程序其實就是使用者在通路SharePoint時候的一個服務程序載體，我們可以把使用者通路一個網站的過程，想象成一個顧客到酒店辦理入住的過程，IIS應用程式池有個最大的連接配接數，預設是1000，就是說一個池子裡面最多可以接受1000個使用者來連接配接，第1001個通路網站的人将提示無法通路。還有一個是隊列長度，預設情況下，一個使用者通路網站，會由一個W3WP程序來和他互動，W3WP程序你可以了解成酒店的前台人員，由他來幫助使用者辦理入住業務。隊列長度就可以了解為排隊長度，隻有一個一個的辦理，這樣才能夠正常有序的進行下去，無論後面對少人排隊，都得一個一個來。

但是一個應用池，其實是可以對應多個W3WP程序的，就會有多個前台接待員來幫助使用者辦理入住，也就是會有多個程序來協助處理互動請求，來為使用者提供服務，這樣就自然而然的提升了網站的通路效率。

針對SharePoint的應用池，我們建議大家主要是針對80端口的主站點池，多啟用幾個W3WP就夠了，在池子裡面找工作程序數，建議從2個開始設定，如果記憶體和CPU充足的話，可以設定成4個。

預設情況下池子和W3WP是一一對應的，我們自己可以改成一對多。這個最大工作程序數，同樣我們在IIS應用程式池進階設定裡面可以找到，如下圖。

<a href="http://s3.51cto.com/wyfs02/M00/8F/07/wKioL1jR4muC7PDOAALdhVPuZL4620.png" target="_blank"></a>

具體啟用多少個程序數，這個根據大家記憶體的占用率來看，日常工作中如果記憶體已經很高了，這裡的數值也不要設定的太高，可以先設定成2個來看一看效果，随後酌情遞加。

這裡還要給大家提一點，預設情況下，應用程式池會有一個空閑回收的操作，20分鐘之内，如果沒人通路這個池子，沒人來出發，也會回收。

是以我們在這裡可以通過下面兩個參數進行更改，建議大家講空閑逾時操作改為終止，閑時逾時時間設定長一些，比如12個小時沒人通路，再進行終止操作。

<a href="http://s3.51cto.com/wyfs02/M01/8F/09/wKiom1jR4m6ivNwqAAMVv9YC5m4550.png" target="_blank"></a>

最後再來給大家分享一個IIS裡面的最後一個需要優化的内容-----IIS重置回收

什麼是重置回收呢？簡單來講，就是一個味了防止池子回收，使用者通路出現中斷，預設情況下 session和記憶體狀态都存在池子裡面，這是為了減輕SQL的負擔，但是随之也帶來了一個問題，既然Session在池子裡面，池子回收了，池子都重新開機了，那我們使用者的Session怎麼辦呢？如果使用者正在進行很重要或者緊急的連接配接呢，這個過程是不允許被中斷的，如果池子回收了，連接配接也斷了，不是就完蛋了麼？

“重置回收”就是我們需要的一個選項，隻要我們開啟了重置回收之後，就能實作一種效果，當池子要回收的時候，會自動在啟動一個程序來接管目前使用者的請求，Session也會一起轉載過去，確定使用者不會因為網站的回收而斷開連接配接。如果不開啟這個重置回收的選項，那麼當發生應用池回收的時候，使用者的Session一定會斷掉。

有些做開發應用的同學應該知道這個，Session一般很有講究，甚至有時候會單獨部署一台Session Server來存放Session，不把Session放到記憶體裡面，目的就是為了防止此類事件的發生而給使用者帶來的困擾。

大家可以在應用池的進階選項中找到這個重置回收選項，英文版的使用者一定要記得“負負得正”喲！

<a href="http://s3.51cto.com/wyfs02/M01/8F/07/wKioL1jR4nGwQvPHAALXlY4tLzw111.png" target="_blank"></a>

如果存在嚴重依賴Session的應用程式，一定要開啟這個設定。這個設定不僅限于提供給SharePoint哈，一切和IIS相關的連接配接應用都有效。

其實SharePoint還好，在多伺服器場中的SharePoint是共享Session機制，幾台前端Web Server共享Session, 即使一台掉了， Session還是可以在其他機器上面找到。但是也不排除一種極端情況，就是多台前端Web伺服器在同一時間點都在做回收操作，如果是這樣，那麼這個Session也會斷掉，是以處于保險起見，開一下重置回收并沒有壞處。

但是如果是 All IN ONE 單台部署的小夥伴就要注意了，這個選項十分的重要哈！

     本文轉自horse87 51CTO部落格，原文連結：http://blog.51cto.com/horse87/1909113，如需轉載請自行聯系原作者