安全性

　　在性能與用戶關心的Web服務器安全性之間找出平衡點是您將面對的重要問題之一，尤其是當您經營電子商務網站更是如此。因為安全的網絡通訊比不安全的網絡通訊需要更多資源，所以知道何時應使用不同的安全技術 (如 SSL 通訊協議或 IP 地址檢查)，以及何時不該使用它們是很重要的。例如，您的首頁或一個搜尋結果頁幾乎不需要通過 SSL 執行。但是，當用戶進入一個結帳或采購網頁時，您就需要確定該頁是安全的。

　　如果使用 SSL，則請注意，建立初始連接比重新連接已經在 SSL 有效期緩存中的安全信息的成本要高上五倍。SSL 有效期緩存的默認超時時間，已經從 Windows NT 4.0 中的 2 分鐘改變為在 Windows 2000 中的 5分鐘。一旦這個資料被清除時，客戶端及服務器就必須建立一條全新的連接。如果打算支持長時間的 SSL 有效期，則可利用 ServerCacheTime 注冊表設置來延長這個超時時間。如果預計會有幾千位用戶使用 SSL 連接到您的站點，則較安全的方式是預估需要 SSL 有效期持續的時間，然后將 ServerCacheTime 參數設成比您預估的時間稍長一些。請勿將超時時間設置值超過此參數，否則您的服務器會在緩存中留下舊的資料。此外， 請確定 HTTP Keep-Alives 已啟用。除非瀏覽器明確地關閉連接，否則 SSL 有效期與 HTTP Keep-Alives 并用時不會超時。

　　除了具備高性價比的所有安全性技術外，Windows 2000 及 IIS 5.0 安全性服務也整合到一些操作系統服務中。這表示您無法從這些服務的其它領域個別監視安全性性能。反之，測量安全性是否消耗系統資源最常用的方式是執行測試，分別比較有安全性功能及沒有安全性功能時的服務器性能有何不同。此測試在進行時必須使用固定的工作量及固定的服務器設置，讓安全性功能成為唯一的變量。在測試期間，您可能需要測量下列項目︰
　　
　　·處理器活動及處理器隊列︰驗證、IP 地址、檢查、SSL 通訊協議，及加密安全性是需要特別處理的安全性功能。您可能會在專用模式或用戶模式中看見增加的處理器活動，以及內容切換與中斷的比率增加。如果服務器中的處理器不足，無法處理增加的負載，便可能形成隊列。密碼加速器之類的硬件在這里可能會有所幫助。

　　·如果正在使用 SSL 通訊協議，則 lsass.exe 可能會耗用驚人的 CPU 容量。這是因為 SSL 進程是在這里進行。這表示習慣在 Windows NT 中監視 CPU 使用情況的管理員會看見 Inetinfo.exe耗用較少的處理器，但 Isass.exe 卻耗用很多。

　　·使用的物理內存︰安全性需要系統存放及獲取更多用戶信息。此外，SSL 通訊協議可以使用長識別碼-40 位到 1,024 位-來加密及解密信息。

　　·網絡傳輸量：您也可能會在 IIS 5.0 的服務器，及用來驗證登入密碼并驗證 IP 地址的域控制站之間，看見增加的傳輸量。

　　·等待時間及延遲︰復雜的安全性特性 (如 SSL) 導致最明顯的性能降級就是花在加密及解密的時間和精力，因為這兩者會使用大量的處理器循環。從使用 SSL 通訊協議的服務器上下載文件比不使用 SSL 的服務器下載文件會慢上10 到 100 倍。

　　如果服務器不僅用來執行 IIS 5.0，還作為域控制站使用，則域服務所耗用的處理器用量、內存、網絡及磁盤活動的比例可能會因為這些資源上而帶來明顯的增加。增加的活動足以讓 IIS 5.0 服務無法有效地執行。強烈建議您避免在域控制站上執行 IIS 5.0。

　　監視網絡應用程序

　　使用一個設計完善且已徹底測試過的應用程序來升級或替換一個撰寫不佳的應用程序，可以顯著地增強性能 (有時可增加到三倍)。不過，請記住您的網絡應用程序可能會受到后端等待時間的影響 (例如 A4/400 等較傳統系統)。遠程資料來源會引起性能問題的原因很多。如果開發人員將應用程序設計成從另一個網站上取得資料，但目標網站卻出現當機，則該應用程序會在您的服務器上造成瓶頸。如果應用程序正在存取遠程 SQL 服務器的數據庫，則該數據庫可能無法跟上傳送給它的請求。因為您可能是自己站點的 SQL 數據庫管理員，所以要監視這些位于遠程的服務器可能會有困難。更糟的是，您可能沒有這些數據庫服務器或其它后端服務器的控制權。如果可以的話，請監視與您的應用程序一起使用的后端服務器，并將它們調整得與您的Web服務器一樣的好。

　　若要判定您的 Web 服務器是否正在您的服務器上造成瓶頸，請監視下列性能計數器︰

　　·Active Server Pages︰Requests/Sec、Active Server Pages︰Requests Executing、Active Server Pages︰Request Wait Time、Active Server Pages︰Request Executing Time 及 Active Server Pages︰Requests Queued。如果正在服務器上執行 ASP 應用程序，則這些計數器可讓您了解這些應用程序執行的狀況有多好。「Active Server Pages︰Requests/Sec」不含靜態文件或其它動態內容的請求，它會根據 ASP 網頁的復雜度及您 Web 服務器的容量明顯地變動。如果這個計數器在服務器上的傳輸量處于尖峰期間出現低值的話，則您的應用程序可能會導致瓶頸。「Requests Executing」顯示目前正在執行的請求數目；「Request Wait Time」顯示最近的請求在隊列中等待的毫秒數；「Request Execution Time」顯示最近的請求花在執行上的毫秒數。理想的狀態是「Requests Queued 」及「Request Wait Time」應保持接近 0，但它們會在不同的載量下起伏變動。最大「Requests Queued」數目是由 AspRequestQueueMax 的 Metabase 設置來決定。如果達到此限制，則客戶端瀏覽器將顯示 [HTTP 500/ 服務器太過忙碌]。如果這些數字大幅偏離了預計的范圍，則您的 ASP 應用程序可能必須重寫才能提高性能。由于「Request Execution Time」并非一個平均值，所以會有些誤差。例如，如果您固定會接收一頁 30 個請求，每頁是以 10 毫秒到 500 毫秒的速度執行每一個請求，則即使平均執行時間超過 25 毫秒，但是計數器可能會顯示 10 毫秒。要為「Requests Executing」說出一個最適當的值很難。如果頁面執行得很快，而且不會等待 I/O (加載文件或提出數據庫查詢)，則這個數字可能會比較低 (比機器忙碌時的處理器個數低一些)。如果頁面必須等待 I/O，則執行的頁數可能會較高 (接近 AspProcessorThreadMax 乘以處理器個數的值)。如果「Requests Executing」的值是高的、「Requests Queued」是大的，而 CPU 的使用率是較低的，則可能必須增加 AspProcessorThreadMax。啟用時，傳送的線程會試著最佳化「Requests Executing」。用戶的響應時間會與「Request Wait Time」加「Request Execution Time」加網絡等待時間的和成比例。

　　·Web Service: CGI Requests/sec及 Web Servcie: ISAPI Extension Requests/Sec 會報告您的服務器是以哪個速度處理 CGI 及 ISAPI 應用程序請求。如果這些值在負載增加時降低，則可能必須請求應用程序開發人員重新檢查他們的程序代碼。
附注-ASP 是個「ISAPI Extension」，包含在第二個計數器中。

　　·Web Service: Get Requests/sec及Web Service: Post Requests/Sec 反應這兩個常見 HTTP請求類型是以哪個速度出現在您的服務器上。「Post Request」通常是用于窗體，并傳送到 ISAPI (包括 ASP) 或 CGI。「Get Request」會記錄幾乎所有來自瀏覽器的其它請求，并包括靜態文件、APS 與其它 ISAPI 的請求，以及 CGI 請求。


調整 Web 應用程序

　　IIS 5.0 對于服務靜態 HTML 網頁及配上默認的設置值基本就已足夠了。如果您的站點主要是靜態內容，則許多性能問題可能會與硬件有關。IIS 5.0 為 Web 應用程序提供不錯的性能，但若想獲得最佳的性能，還需要一些額外的調整。當然，不管服務器軟件如何增強，與 Web 應用程序設計及程序代碼有關的最佳經驗方法的問題依然會存在。雖然本文沒有試圖討論調整 Web 應用程序的細節，但本節仍提供一些使它們執行更快的指導及建議。在規劃及測試您的 Web 應用程序時，請先考慮下列事項，然后再到實際聯機運行的服務器上執行它們。

　　第一，ISAPI 應用程序比 Active Server Pages (ASP) 應用程序執行得更快，雖然 ASP 的開發費用遠比 ISAPI 低。這兩種應用程序都比 CGI 應用程序執行得更快。

　　第二，因為靜態文件不會有動態文件才有的處理負載，或引起磁盤活動，所以您應該盡可能使用它們。除了使用靜態文件外，您的應用程序應盡可能將處理負載推到客戶端，以避免網絡等待時間。如此也能節省服務器端的資源，并讓更新在很段時間內完成。有個常用的范例是加一個客戶端的小程序代碼，來檢查電子郵件地址組成是否正確。

　　另一個技巧是確定在您的實際上線運行服務器上已關閉 ASP 的偵錯功能。如果啟用偵錯，則必須將 AppAllowDebugging Metabase 屬性設為 FALSE。相關信息，請參閱〈附錄 1︰性能設置〉。

　　盡可能地為所有圖像及 HTML 設置「過期」標題，讓它們可以存放在客戶端的緩存中。相關信息，請參閱本文中的〈調整及疑難排除的建議〉小節。

　　如果 Microsoft Visual Basic_ 對象是以 Apartment 線程處理的(非 Java 或大部分 C++ 對象)，請從「ASP 應用程序及有效期」狀態中刪除它們。

　　只有在必要時才使用 Secure Sockets Layer (SSL)。使用 HTTPS 通訊協議比使用標準 HTTP 貴很多。請確定傳送中的信息 (可能是敏感資料如信用卡號) 的價值是否值得您付出增加的費用。安全性調整問題的相關信息，請參閱本文中的〈安全性〉小節。

　　進程隔離也會影響 Web 應用程序的性能。IIS 5.0 Web 應用程序默認是在進程外的緩沖池 (中度保護) 中執行。接受進程隔離對性能的影響總比冒著服務器停機或資料遺失的風險來的安全，例如因應用程序當機而破壞它與 IIS 5.0 共享的 Ientinfo 進程時就會導致這些風險。有關這個主題的深入討論，請參閱本文中的〈進程隔離〉小節。

　　若要增進生產環境中的數據庫驅動性能，請使用 Microsoft SQL Server。由于 IIS 及 SQL Server 在足夠的內存下執行的情況最好，因此請嘗試將資料庫存放在不同于 Web 服務的服務器上。在這種情況下，經由網絡跨計算機通訊通常比單一計算機上的通訊還快。當 SQL Server 及 IIS 存放在同一臺服務器上時，就會經常因為內存不足或循環不夠而導致性能降低。此外，請務必建立及維護適當的索引。如此才能最小化數據庫查詢的輸入和輸出。最后一點，請盡量多利用被存儲的過程(stored procedured)。它們比設計來執行相同工作的 ASP 腳本文件所需的執行時間更少，而且更容易撰寫。

　　一般來說，如果您有個超過 100 行 (使用 #include 指令來計算添加文件中的程序代碼行數) 的 ASP 腳本文件，請考慮建立一個 COM+ 組件來提供相同的功能。如果能撰寫得很有效率，并且經過正確地的測試，則 COM++ 組件可以為同一動態頁提供 20 到 30 倍處理一個腳本文件的速度。使用 #includes 測量 ASP 腳本文件最簡單的方式是將擴展名從 .asp 改為 .stm，并使用您的瀏覽器開啟 .stm 檔。您的瀏覽器會顯示此 .asp 文件，以及來自該已包含文件(included file)中的程序代碼。

　　若要最佳化動態網絡應用程序的性能，很重要的一項工作是讓您的應用程序正式在站點上啟用前，先測試它們。執行這項工作有個很好用的工具--Web Application Stress (WAS) 工具，您可以從 Microsoft Web Application Stress Tool 站點 下載它。在這個站點上還包括專為此工具提供的教學指南及知識庫。WAS 也內含在 Windows 2000 Resource Kit 附隨 CD 上。本 CD 上亦有。
測量網站服務器及應用程序所需工具的相關信息，請參閱本文中的〈用來監視及測試服務器性能的工具〉小節。如需網絡應用程序性能及測試該性能所需工具的鏈接及參照清單，請參閱本文中的〈資源〉小節。
監視及測試服務器性能的工具

　　為了支持您的性能調整及測試需求，Microsoft 提供幾個工具︰有些內含在 Windows 2000 及 IIS 5.0 中、有些位于 Windows 2000 Resource Kit CD中，剩下的內容則可從 Microsoft 網站下載。「系統監視器」(先前稱為 PerfMon) 內建在 Windows 2000 中，它對于監視服務器的各種性能而言是必要的。「進程及線程狀態」(pstat.exe) 會顯示所有執行中的進程及線程的狀態。「進程樹狀目錄」(ptree.exe) 可讓您查詢進程的繼承樹狀目錄，及刪除本機或遠程計算機上的進程。這些工具都提供在 Windows 2000 Server Resource Kit 附隨 CD 上。提供在 Windows 2000 Resouce Kit 附隨 CD 上的「HTTP 監視工具」會監視服務器上的 HTTP 活動，而且會在活動容量發生改變時通知您。「網絡監視器」是個您可以用來維持固定網絡傳輸量的 Windows 2000 管理工具。它不包含在默認安裝中，不過使用 [控制面板] 的 [添加/刪除程序] 功能可以安裝它。NetStat 是個指令行工具，會偵測關于服務器目前網絡連接的信息。

　　這些工具的中心是內建在 IIS 5.0 及 Windows 2000 操作系統中的「性能計數器」。開發人員也可以在他們編寫的 ISAPI DLLS 或 COM 組件中添加自定義的的「性能計數器」。這些計數器可以由以上提到的一些工具直接讀取，包括「系統監視器」及「Web 應用程序壓力工具」和 WCAT。其中有些計數器在本文前面已作過說明，但了解哪些會關系到您的監視及測試需求是很重要的。

　　「系統監視器」是一個在Web服務器上建立性能基準，并監視您對軟硬件所作的任何改變，對性能將產生哪些影響的最重要工具。「系統監視器」提供一個用戶接口，讓您在監視或記錄時能看見性能計數器的指數。它也能讓您以圖形方式記錄計數器活動，并設置將出現在 [事件查看器] 中的警告。「系統監視器」提供系統中每一計數器的記錄。

　　「Web 應用程序壓力」工具是專門為了仿真多個瀏覽器同時向一個網站送出網頁請求而設計的。您可以使用這個工具來收集關于 Web 應用程序性能及穩定性的信息，以及服務器執行狀況的信息。這個工具可以仿真利用少數的客戶端機器向 Web 服務器送出大量的請求時的狀態。其目的是為了建立一個與生產環境盡可能相似的環境。如此才能讓您在將 Web 服務器及應用程序部署到聯機運行的服務器上之前，先找出并消除其中存在的問題。

　　以上任一工具的相關信息，請參閱內含在 Windows 2000 Resource Kit 中的聯機IIS 5.0 文件。指向其它信息來源的鏈接則內含在本文的〈資源〉小節中。