30 天也快到尾聲了，IIS 中我認為比較重要的模組跟功能我都有大致在前面的文章帶過。一些較少或使用情境較為獨特專一的模組，如果日後我有那個心或經驗，我會再看看怎麼補上。整理前面做總結這種事情，是第 30 天做的，還不是今天的菜單。

那今天的菜單是什麼呢，前面這個引言不就是有種要手牽手大合唱的感覺了嗎？也算是啦，今天想要談的是關於設定的優化。不知道大家有沒有聽過 Best Practice 這個詞？這個詞最開始應該是源自於管理學(by wiki)，指的是公認(由具公信力的組織或群體做出的認定)一套能夠達到泛用情況下最優結果與減少出錯的方法或機制，做軟體工程或任何管理方法，我們常常都會談到最佳實踐這個詞。

設定百百種，狀況萬萬種，我們該怎麼從茫茫設定海中有一套能夠依循或判斷的標準？這時候就是尋找該項技術或方法論的最佳實踐文章了，當然最佳實踐的最佳認定是寫的那個人或群體的認定，所以是不是真的最佳，觀者有心，能夠自己判斷。最佳實踐往往不會武斷地寫說怎麼樣一定好，而是會好好地說清楚前提與設定的關係，什麼情況什麼前提下，這樣的設定是一個值得參考的設定，如果有什麼樣的顧慮，就應該怎麼樣去處理，諸如此類，讓閱讀最佳實踐的人能夠從中思考並套用到自己的狀況中，為自己量身調整合適的版本。

標題的句子來自希臘先哲亞里斯多德的名言 "We are what we repeatedly do. Excellence, then, is not an act but a habit."，中文是這麼說的「我們的重複行為造就了我們，所以卓越不是一種行為，而是一種習慣。」了解最佳實踐，知道原理，能夠協助我們在同樣的情景，或各種零碎的步驟中有所依循，建立穩固的設定基礎，才能夠讓整體服務更加穩定可靠。

IIS 的設定那麼多，也是有各種觀點的 Best Practice，如考量 Performance 和 Security 的作法可能就有出入，這裡我會就我自己閱讀多篇相關文章和個人經驗，和大家就不同的角度分享一些設定的數值與思考方向，讓大家在考慮調校自己的服務的時候能有個參考。記得，所有的分享都有它的前提，請比較好敘述中的前提與你的狀況是否相符，再斟酌是否套用，能測試的永遠先在測試環境做過測試，減少意外的產生。部分內容可能在前面寫該項主題時就有寫過，這篇就當作是個小整理吧。

上半段我們先聊聊關於 Application Pool 和 Log，有在管理 IIS 與網站的人應該都知道 Application Pool 對網站來說多重要，肩負了 Process 相關設置；Log 更不用說，就像除錯汪洋中的一根浮木，需要的時候很有可能是你的一盞明燈。讓我們開始看看有那些設定觀點吧。

(本次的上下篇內容會大量參考 IIS Best Practices 此篇文章，部分解釋可能不盡相同，該篇文章對解釋的著墨可能有些的地方少了點，有些點則是我沒提到，你可以把這篇文章也作為參考)

Application Pool

• 每個 Application，都應該有各自的 Application Pool
  目的是避免單一 Process 出問題時連帶影響多個 Application 的服務；除非你的網站數量真的非常的多，而且服務穩定性很高，才可能考慮 Application Pool 的共用，但目的僅是為了管理方便，說到穩定性，拆分肯定是更穩妥的選擇
• 不同的 Application Pool 應有各自拆分的 Identity
  讓每個 Application Pool 的 Identity 都僅能存取自己需要的資源，這也是為什麼 IIS7 後出了 AppPoolIdentity 這個選項，避免單一身分的過大權限，甚至包含各自的 temp folder 能獨立也能減少彼此交互影響的機會
• 務必依照自己的情境去設置 Application Pool 的 Recycle
  在可能的情況下應該要定時做 Process 的 Recycle， Recycle 可以解決很多潛在的問題。記得把預設的 1740 調成 0 避免不規律的時間點遭到 Recycle，而是用定時 Recycle 在 Out of business hour / Non pick hour 時做回收。如果你對你的 Application 在資源使用上的控管非常有信心，不會有任何 Memory Leak 的問題、其他不良寫法導致系統資源占用，Disabled Recycle 也是一種選項，但就要更注意 w3wp.exe 的資源佔有成長速度。

• Application Pool Recycle 時的會寫入 Log 的情境保持全部為 True (預設就是全部為 True)(Application Pool Advance Settings)
  你不會想 Application Pool 被莫名其妙 Recycle 了結果還找不到原因的
• 在設置 Maximum Work Process 時要特別注意自己的 Application 是否適合
  跨 Process 間是不互通 Session 、Cache 的，所以如果你的 Application 對使用者並非 Stateless，要注意那些 State 儲存的地方在不同 Request 會到不同 Process 間跳躍的情景是否能通用
• Rapid Fail Protection 儘管會停掉你的 Application Pool，請保持這個功能的開啟
  會觸發停掉的狀況多為當下 Application / System 真的有問題，致使 Process 沒有辦法成功地起來，關掉對系統穩定和資源來說並不是件好事，多數情況下即使關掉了也不太可能會讓重啟成功(畢竟本身就有一定次數的容忍)。考量到系統安全性，也許訂閱特定的 event log 搭配 task scheduler 去做警告發信才是更能及時注意到系統問題的方式。

Logging

• 保持 IIS Log 的 Enable，盡可能的在 W3C 的格式下開啟夠多的欄位
  寫入本身是透過 Windows 的 event system 機制去做的，不會直接影響網站本身運行的 Process(除非規格真的差到同時運行會有影響，那應該要調整規格)，但確實要顧慮寫入 Log 對磁碟的負擔，還有空間的佔用，所以可能的話應該不要直接寫入系統碟。夠多的欄位的定義就比較難說，依據你的 Application 特性，可能有不同的勾選方式，但至少像 sc-bytes、 cs-bytes 這種通用的欄位就可以勾起來
• 承上，注意 Log 的成長速度跟檔案分割
  Log 如果寫入速度異常，無論是過快或過慢都是一個警訊。有能力的話上個能監控 Log 和磁碟空間的工具 / 腳本都是選項。還有 Log 應該要依你的流量大小有合適的分檔方式，如果流量大的網站，一天只寫一個 Log，那個 Log 打不打的開都是個問題(檔案過大)
• Httperr Log 也是一個要注意的地方
  可能多數人會比較注意 IIS Log，不過記得順序上如果更前面 Http.sys 層面就出了問題，很可能不會寫到 IIS Log 該 Request 就被返回了。這次 30 天的內容我也還沒細寫這部分，僅分享一篇官方文章供大家做為參考 Error logging in HTTP APIs - ASP.NET
• 把 Configuration Monitor 開起來
  設定一改，風雲變色。比起到時候大家都說沒有改，有個證據能留下會是好的多的選擇。如果你不知道這條在說什麼，請參閱 Day12 的內容。
• Server 上準備好 Fail Request Tracing 的模組，但平時可以保持關閉
  FREB 的強大前兩篇剛討論過，但越詳細的資料記錄相對就有一定負擔，所以平時是設置好、安裝好模組但 disabled 它(避免需要時手忙腳亂，還要去臨時查找設定方法)，僅在需要除錯時開啟讓它在對的時間提供幫助

上篇到此先歇會，下篇我們會就 Security / Performance / 其他雜項的部分來為大家分享其他的 Best Practice 項目與原因。