對於喜好以開放原始碼為基礎的IT人員來說，通常比較偏向選擇Linux下的網站平台，主要的原因之一是認為Windows的IIS網站平台效能較差，然而真是如此嗎？其實這可真是一件天大的誤會！現在就來學會IIS網站的優化技巧，讓這個長久以來的迷思就此終結。
此外，要注意的是，如果打算透過「伺服器管理員」介面來安裝IIS伺服器角色，除了選擇將它安裝在本機之外，還可以將其安裝在受管理的其他Windows Server 2012 R2伺服器內，或者所選取之離線虛擬機器的虛擬硬碟之中。
以效能監視器找出效能瓶頸
無論是哪個版本的Windows Server，內建的「效能監視器」始終是系統管理人員進行效能校調時的必備工具。透過效能監視器，不僅可以找出作業系統本身的運作問題，對於許多安裝在系統內的Microsoft應用服務，如大家所熟知的Exchange Server、SQL Server、SharePoint以及Skype for Business等解決方案的效能癥結，也都能夠透過它來協助發現背後真正的問題所在。既然如此，那麼藉由它來找出IIS網站應用程式效能不佳的問題，那就更不費吹灰之力。
從「伺服器管理」介面中的「工具」選單，點選開啟「效能監視器」。在系統預設狀態下，效能監視器只有加入「Processor Time」計數器，而且是對於所有CPU的核心進行監視。此計數器幾乎是針對任何應用系統效能問題進行持續監視時的必要選項，因為它可以做為其他計數器狀態的相對參考指標。
在如圖1所示的範例中，特別額外加入ASP.NET Application的相關計數器，以及PhysicalDisk的「Current Disk Queue Length」計數器，其目的在於觀察現行IIS網站應用程式，在面對不同連線流量衝擊時，所相對呈現的CPU負載與實體磁碟佇列長度的狀態變化。
 |
| ▲圖1 善用效能監視器。 |
當然，可以加入更多不同的計數器來動態觀察它們之間的相互關係，例如比對目前網站連線要求數量（Request Current），以及它對於每一個連線要求的執行時間（Request Execution Time），如果經常性保持回應的時間過長，這時候就可以觀察「Processor Time」計數器、Memory的「Available MBytes」計數器，或是PhysicalDisk的「Disk Time」計數器變化。
倘若這三者之一的計數器呈現持續維持在高點的情形，就表示相對的硬體資源效能不足，有替換或升級的必要性。但如果這些硬體資源並沒有相對呈現高點，則可能的問題通常與應用程式本身或後端資料庫結構的設計有關。
圖2所示便是新增計數器的設定範例，一般來說對於IIS網站應用程式效能表現的監視，除了會加入各硬體資源的計數器之外，也會加入前面所介紹過的ASP.NET Application相關計數器。
 |
| ▲圖2 新增計數器。 |
另外，Web Service的相關計數器也是重要的參考指標，因為它可以讓管理者知道在當下目前匿名與非匿名的連線數量、每秒嘗試連線的數量、每秒傳遞與接收的速度、Post以及Get或CGI每秒的連線要求數量、總接收與傳遞的檔案數量、非同步I/O頻寬的使用率、每秒嘗試登入的連線數量等等，這些都是值得用來診斷網路效能與網站是否遭受攻擊的重要依據。
如圖3所示，有時候對於各計數器的狀態值比較，會選擇採用長條圖方式來呈現，原因是能夠更快地看出它門之間的相對關係，不過這種檢視方式通常使用在較少數量的計數器觀察，例如只要觀察Request Execution Time與Processor Time、Disk Time三者計數器的比較。
 |
| ▲圖3 以長條圖顯示。 |
若打算持續一段時間以長條圖呈現方式，來觀察網站應用程式的效能表現時，最好能夠開啟每一個計數器的內容，如圖4所示修改所要呈現的色彩、寬度、刻度以及樣式，藉此更視覺化地觀察它們各自的變化。
 |
| ▲圖4 設定計數器資料。 |
從IIS站台運行記錄發現可疑行為
針對IIS網站效能不佳的問題，有些時候可能不是系統配置或開發設計方面的原因所致，而是網站本身遭受了惡意的大流量攻擊，像許多年以前發生過大規模的CodeRed、納坦蠕蟲病毒就癱瘓了不少企業網站。
值得一提的是，如果有啟用SMTP服務功能，但卻沒有妥善配置安全性設定，也有可能遭受到非法的E-mail轉寄，而成為名符其實的黑客跳板（Relay Host），不僅會使得發信服務癱瘓，更會因此成為網際網路的黑名單，而得花上許多時間來解除。
其實，無論是哪一種類型的網路服務遭到癱瘓，其根本原因都是因為系統安全配置不當，或系統設計本身出現明顯的漏洞，而這一類的攻擊手法全部都有跡可循，且全都可以從服務本身的記錄檔找到完整內容。以IIS網站服務來說，就可以辦到。