· 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 指令。
安全性
在性能與用戶關心的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 應用程序，則這些計數器可讓您了解這些應用程序執行的狀況有多好�！竌ctive server pages︰requests/sec」不含靜態文件或其它動態內容的請求，它會根據 asp 網頁的復雜度及您 web 服務器的容量明顯地變動。如果這個計數器在服務器上的傳輸量處于尖峰期間出現低值的話，則您的應用程序可能會導致瓶頸�！竢equests 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請求類型是以哪個速度出現在您的服務器上�！竝ost request」通常是用于窗體，并傳送到 isapi (包括 asp) 或 cgi�！竒et request」會記錄幾乎所有來自瀏覽器的其它請求，并包括靜態文件、aps 與其它 isapi 的請求，以及 cgi 請求。
//
文章來源于領測軟件測試網 http://www.kjueaiud.com/