為什么要調整 Web 服務器？

　　調整您的 Web 服務器有幾個有利于商業上的考慮。第一，因調整而提高性能，進而縮短了等待服務器響應的時間，可讓用戶獲得更好的經驗。調整將有助于避免使用上的瓶頸，并可讓你的硬件使用更久，并且不用經常升級或是拉長為你的 Web Farm 購置新服務器時間。如此能讓您在真正需要購買例如內存、處理器或網卡等零件時還有預算。
除了這些商業上的考慮之外，還有一些技術上的原因與調整Web 服務器性能有關。調整可讓您充分利用既有的硬件，并決定此時及日后要執行哪些升級。通過調整 Web 服務器，您可以最大化網絡應用程序的生產力并最小化響應時間，同時判定其中哪幾個應用程序正按請求處理高負載。


需要調整的內容

　　調整 Web 服務器的困難之一是如何精確地知道要調整什么。基于這個理由，在調整設置、硬件、Web 服務器，或甚至升級到 Windows 2000及 IIS 5.0 之前，先監視 Web 服務器是很重要的。這點是再怎么強調都是不夠的：收集關于您服務器的基準信息可讓您了解它們的行為，并精確制定出Web 服務器性能的目標。您可以使用內建在操作系統及 IIS 中的 [性能監視器] 及 [性能計數器] 來建立此基準。一旦收集基準信息后，請分析它們以判定在作一個改變 (不論是添加 RAM 或調整內部 IIS 設置也好) 之前，可能會有哪些性能問題的潛在原因。一旦作了改變，請記得再次監視服務器。您所作的改變可能會在您系統的其它組件上造成無法預測的影響。

　　這個主題分成五小節：硬件調整議題、Web 應用程序調整議題、用來監視及壓力測試系統的工具、安全性考慮、影響 Web 服務器性能的 Windows 2000 及IIS 5.0 內部設置。

　　請注意，這些議題相互之間并無關聯。要從升級硬件來修改內部設置的話，調整Web 服務器將需要您仔細地監視任何改變對Web 服務器性能的影響。

監視硬件
內存

　　通常系統中所發生的問題是由于內存不足所導致出來的問題，這是較常見的。您應該先監視內存，確認您的服務器有足夠的內存，再于其它組件上增減。若要執行 Windows 2000 上的 IIS 5.0，一個專用Web 服務器所需 RAM 的最小容量是 128MB，但最好是 256MB 到 1GB。額外的內存對于電子商務站點、含大量內容的站點、處理高傳輸量的站點尤其適用。因為「IIS 文件緩存」默認是使用最多一半可用的內存，因此您備有的內存越多，「IIS 文件緩存」就越多。

　　附注：Windows 2000 Advanced Server 最多可支持 8GB 的 RAM，但是「IIS文件緩存」將不會利用 4GB 以上的 RAM。

　　若要判定服務器上目前的內存容量是否能滿足您的需求，請使用內建在Windows 2000 中的 [性能] 工具 (先前稱為 PerfMon)。屬于 [性能] 工具一部份的 [系統監視器] 會隨著計數器指數的改變而以圖形顯示。

　　此外，請留意您的緩存設置--只添加內存不一定能夠解決性能問題。您必須留意 IIS 緩存處理設置以及它們如何影響服務器的性能。如果這些設置對放置在服務器上的負載并不適當的話，則可能不是發生內存不足，而是造成性能瓶頸。這些緩存設置的相關信息，請參閱本文中〈IIS 設置〉及〈附錄 1：性能設置〉兩節中的說明。如需關于使用 ASP 及 IIS 緩存的討論，請參閱〈附錄 3：ASP 緩存處理〉。

　　附注：在使用 [性能] 計數器來監視性能時，可以在 [添加計數器]對話框中任選一個計數器，并按一下 [說明] 來查看該計數器的說明。
請記錄下列計數器，以判定是否有和內存相關的性能瓶頸：

　　·內存︰可用的字節。試著保留至少 10% 的可用內存，以供尖峰時間使用。請記住 IIS 5.0 默認最多會使用 50% 的可用內存，供文件緩存使用。

　　·內存︰Page Faults/sec、Memory︰Pages Input/sec及Memory︰Page Reads/sec。如果有個程序請求內存中的一頁，但系統無法在所需的位置上找到它，就會構成一個分頁錯誤。如果此頁位于內存中的其它位置，則此錯誤便稱為軟件分頁錯誤。如果必須從磁盤獲取此頁，則此錯誤便稱為硬件分頁錯誤。大部分的處理器可以處理大量的軟件錯誤而不會引起任何后果。但是，硬件錯誤卻會導致嚴重的延遲。「Page Faults/sec」是指處理器處理錯誤頁 (包括硬件及軟件分頁錯誤) 的整體速度。「Pages Input/sec」是指為了解決硬件分頁錯誤而從磁盤讀取的總頁數。「Pages Reads/sec」是指為了解決硬件分頁錯誤而讀取磁盤的次數。「Pages Input/sec」會大于或等于「Page Reads/sec」，并且能夠清楚地讓您了解硬件分頁錯誤率。如果這些數字都很低，則服務器應該可以快速地響應請求。如果很高，則可能是因為您用了太多的內存在緩存處理上，而沒有留足夠的內存供系統的其它部份使用。您可能必須在服務器上添加 RAM 的容量，但是降低緩存的大小也是可行的。

　　·內存︰Cache Bytes、Internet Information Services Global︰File Cache Hits %、Internet Information Services Global︰File Cache Flushes，及 Internet Information Services Global︰File Cache Hits。第一個計數器「Memory : Cache Bytes」顯示「文件系統緩存」的大小，其默認為最多使用 50% 的可用物理內存。由于當緩存的內存快要不足時，IIS 會自動調整它，所以請留意這個計數器行進的方向。第二個計數器是緩存存取次數與緩存請求總數的比例，它會反應出此「IIS 文件緩存」的設置表現的好不好。對于主要由靜態文件組成的網站來說，80% 以上的緩存存取次數應是個不錯的數字。請比較最后兩個計數器的記錄文件「IIS Global: File Cache Flushes」及「IIS Global︰File Cache Hits」，以判定您是否正以適當的速度將對象從您的緩存清除。如果清除發生太快，則對象可能會比其應有的頻率更常從緩存中清除出來。如果清除發生太慢，就會浪費內存。請參閱〈附錄 1︰性能設置〉中關于ObjectCacheTTL、MemCacheSize及 MaxCachedFileSize 對象的說明。

　　·Page File Bytes : Total。這個計數器反應出系統上分頁文件的大小。分頁文件越大，系統提供給它的內存就越多。Windows 2000 會自動在系統磁盤驅動器上建立一個分頁文件；您可以在每一個邏輯磁盤上建立一個分頁文件，并改變現有文件的大小。事實上，將一個分頁文件等量分配到不同物理硬盤上可提升分頁文件的性能 (請使用不含您的網站內容或記錄文件的硬盤)。請記住，系統磁盤驅動器上的分頁文件至少應是物理內存的兩倍大，這樣系統才能在發生當機時，將整個 RAM 的內容寫入磁盤中。

　　·Memory: Pool Paged Bytes, Memory: Pool Nonpaged Bytes, Process: Pool Paged Bytes: Inetinfo, Process: Pool Nonpaged Bytes: Inetinfo, Process: Pool Paged Bytes: dllhost#n, and Process: Pool Nonpaged Bytes: dllhost。「Memory : Pool Pages Bytes」及「Memory : Pool Nonpaged bytes」會監視服務器上所有進程的緩沖池空間。這里列出的其它計數器會監視由 IIS 5.0 直接使用的緩沖池空間，不管是用于您服務器上進行的 Inetinfo 進程 (即 IIS 在其中執行的進程)，或是 Dllhost 進程 (即把 Web 應用程序從 Inetinfo 隔離或把 Web 應用程序放在緩沖池中一起執行的進程)。請確定監視服務器上所有 Dllhost 例項的計數器；否則您將無法取得 IIS 使用的緩沖池空間的正確數值。系統的內存緩沖池會保留應用程序及操作系統建立及使用的對象。內存緩沖池的內容只能在專用模式下存取。換言之，只有操作系統的核心才能直接使用內存緩沖池；用戶進程則無法使用。在執行 IIS 5.0 的服務器上，服務連接的線程是與該服務使用的其它對象 (例如文件句柄及通訊端) 一起存放在未分頁的緩沖池中。

　　除了添加更多 RAM 外，請嘗試下列技巧以增強內存性能︰改進數據組織、嘗試映像或等量劃分磁盤、以 ISAPI 或 ASP 應用程序取代 CGI 應用程序、加大分頁文件、重新計數「IIS 文件緩存」、刪除不需要的功能，以及將「文件系統緩存」的平衡值改成「IIS 5.0 工作設置」。其中最后一個技巧將在本文稍后詳細說明。

　　若想取得影響這些計數器數字的 Windows 2000 及 IIS 5.0 設置的詳細討論，請參閱〈附錄 1︰性能設置〉。

　　處理器容量 (Processor Capacity)

　　隨著用戶請求從網站獲得快速的響應時間，以及在這些網站上不斷增加的動態內容，更加需要利用到快速、有效的處理器用量。當一或多個進程幾乎耗盡所有處理器時，就會發生瓶頸。這會迫使準備好執行的進程線程必須在隊列中等待處理器時間。添加諸如內存、磁盤或網絡連接等其它硬件，以試圖克服處理器瓶頸的無效，反而會讓狀況更加惡化。

　　Windows 2000 Server 上的 IIS 5.0 能有效地調配二至四個處理器。如果您正在考慮添加額外的處理器，請衡量您網站的業務需求。例如，如果您在服務器上主控的大多是靜態內容，則備有兩個處理器的計算機應已足夠。如果主控的是會動態生成的內容，則備有四個處理器的安裝可以解決您的問題。不過，如果站點上的工作量需要大量的 CPU，則單一計算機將無法符合請求的數量。如果您的站點是這種情況，則應將它調配成跨多臺服務器。如果已經在多重服務器上執行您的站點，請考慮添加更多服務器。

　　不過，您應該明了 Windows 2000 及 IIS 5.0 的最大性能增益來自于解決內存問題。在決定改變Web 服務器上處理器的個數之前，請先排除內存問題，再監視下列「性能計數器」。

　　·System : Processor Queue Length。這個計數器顯示了在由系統上所有處理器共享的隊列中，等候執行的線程數目。如果這個計數器提供了兩個或以上的自變量值，則表示手邊就有一個處理器瓶頸。

　　·Processor : %Processor Time。處理器瓶頸的特征是︰當網絡適配卡及磁盤 I/0 仍保持正常的低容量時，「處理器︰% 處理器時間」的數字卻很高。在多處理器的計算機上檢查「Processor : %Processor Time」計數器來找出任何不平衡的情況是個很好的作法。

　　·Thread : Context Switch/sec:Dllhost#N, Thread: Context Switchs/sec:Inetinfo=>Thread#, System: Context Switches/sec。如果決定增加線程緩沖池的大小，便應該監視這里列出的三個計數器。增加線程數目可能會增加內容切換的數目，因而造成性能不增反降。每一個請求有 10 個或以上內容切換就已經是相當高的數字了；如果出現這些數字，請考慮降低線程緩沖池大小。想通過測量連接及請求來得出線程及整體性能之間的平衡點是不容易的。每次當您調整線程時，請接著監視整體性能，以檢查性能是增進還是降低。若要判定是否應該調整線程計數，請將進程中的每一個線程數目和處理器時間拿來和總處理器時間作比較。如果線程持續忙碌，但并沒有使用全部的處理器時間，則建立更多線程對性能會有幫助。不過，如果所有線程都很忙，而且處理器已快接近最大容量，則最好將載量分配給更多服務器，而不要增加線程的數目。請參閱本文中〈附錄 1︰性能設置〉的AspThreadGateEnabled 及 AspProcessorThreadMax metabase 屬性。

　　·Processor: Interrupts/sec 及 Processor: %DPC Time 。使用這些計數器來判定處理器應花多少時間在中斷及延緩的過程調用上 (DPC)。有兩個因素可能是處理器上負載的其它來源。客戶端請求是這兩個因素的主要來源。有些新型網絡適配卡包括中斷減緩，也就是說當中斷程度太高時，它會將中斷累積在緩沖區中。

　　跨多臺計算機調配

　　如果處理器問題持續存在，請嘗試使用 Network Load Balancing (NLB) 或硬件負載平衡器跨多臺計算機調配您的站點。雖然使用其中一種方法來設置 Web Farm 會增加一層復雜性，并產生一些其它問題，但如果您的網站規模夠大的話，這個操作可能會替您解決一些性能問題。NLB 的相關信息，請參閱 Network Load Balancing Technical Overview。

　　網絡容量、等待時間及帶寬

　　基本上，網絡是客戶端向服務器傳送請求的線路。它花在您的服務器上來回傳遞這些請求及響應的時間，對用戶能察覺的服務器性能來說是個最大限制因素之一。這種請求-響應的循環時間就稱為等待時間，等待時間對于Web 服務器管理員來說幾乎是無法控制的。例如，您對 Internet 上速度緩慢的路由器，或是客戶端及服務器之間的物理距離所能作的處理實在不多。

　　在主要是由靜態內容組成的站點上，網絡帶寬最有可能是性能瓶頸的來源。即使是一般的服務器也可能用滿一條 T3 連接 (45mbps) 或 100mbps Fast Ethernet 連接。您可以通過調整當前的連接，或盡可能最大化有效的帶寬來改善這些問題。

　　測量有效帶寬最簡單的方法是判定您的服務器是以哪個速度傳送及接收資料的。有一些「性能」計數器可以測量您的服務器上許多組件中的數據傳輸。包括 Web、FTP 及 STMP 服務、TCP 對象、TP 對象及「網絡接口」對象上的計數器。每一個計數器都會反應不同的 Open System Interconnectivity (OSI) 層。這些計數器及其分析的詳細清單，請參閱隨 Windows 2000 Server Resource Kit 一起發行的《Internet Information Services 5.0 資源指引》。請特別參閱〈監視及調整服務器〉該章中的〈網絡 I/O〉小節。不過，若要開始使用下列計數器︰

　　·Network Interface: Bytes Total/sec。若要判定您的網絡連接是否正在存在瓶頸，請比較「Network Interface: Bytes Total/sec」計數器與您的網絡適配卡總帶寬。若要在傳送量中留些空間供尖峰時間用，則不應常使用超過 50% 的容量。如果這個數字十分接近連接的容量，而處理器及內存的使用都很適中，則此連接也會是個問題。

　　·Web Service: Maximum Connections 及 Web Service: Total Connection Attempts 。如果您正在計算機上執行的其他服務也使用網絡連接，則應監視「Web Service: Maximum Connections」及「Web Service: Total Connection Attempts」計數器，以檢查您的Web服務器是否能夠盡可能地使用它需要的連接數目。請記得將這些數字與內存及處理器使用量作比較，如此才能確定連接就是問題，而不是其它組件有問題。

　　磁盤最佳化

　　因為 IIS 5.0 會將記錄文件寫入磁盤上，所以在一般磁盤活動中，甚至會有高達 100 % 的客戶端緩存存取次數。一般來說，如果有記錄以外的大量磁盤讀取活動，即表示系統上有其它區域需要調整。例如，硬件分頁錯誤會導致大量的磁盤活動，但它們表示 RAM 不足。
存取內存比存取磁盤快約 1 百萬倍；無疑地，通過搜尋硬盤來響應請求將降低性能。您主控的網站類型對硬磁盤搜尋的頻率影響很大。如果您的網站上有個隨機存取的超大型文件集、如果網站上的文件大多是超大型，或如果 RAM 的容量很小，則 IIS 便無法在 RAM 中維護文件的復本，供更快速的存取。

　　當您的服務器忙碌時您通常會使用「Physical Disk」計數器來監視，磁盤讀取次數的允許范圍。如果 RAM 夠大，則大部分的連接會導致緩存存取，除非您有個存放在同一臺服務器上的數據庫，而且用戶端正在提出不同的查詢。這種情況會阻止緩存處理。請注意記錄也會導致磁盤瓶頸。如果您的服務器上沒有明顯與大量磁盤有關的問題，但卻看見大量的磁盤活動，則應立即檢查服務器上的 RAM 容量，以確定是否有足夠的內存。

　　若要確定磁盤存取的頻率，請記錄下列計數器︰

　　·Processor: % Processor Time, Network Interface Connection: Bytes Total/sec及PhysicalDisk: % Disk Time。如果這三個計數器的值都很高，則硬盤不會引起站點的瓶頸。但是，如果「% Disk Time」的值很高，但處理器及網絡連接并沒有飽和，則硬盤可能會造成瓶頸。如果在您的服務器上沒有啟用「Physical Disk」計數器，請開啟指令行，并使用diskperf -yd 指令。