1. 關鍵效能計數器指標

a. Web服務（W3SVC）效能計數器

• 當前連線數(Current Connections)：顯示當前所有HTTP連線的數量。過高的數值可能表明網站流量過大或連線無法及時釋放。
• 每秒請求數(Requests/sec)：顯示每秒鐘收到的HTTP請求的數量。這可以幫助您瞭解網站的流量。
• 匿名使用者/秒(Anonymous Users/sec) 和 非匿名使用者/秒(NonAnonymous Users/sec)：監控匿名和已認證使用者的請求數有助於瞭解安全需求。
• ISAPI擴充套件請求(ISAPI Extension Requests/sec)：如果您使用ISAPI擴充套件，監控此計數器有助於識別效能瓶頸。

b. ASP.NET效能計數器

• 應用程式重啟次數(Application Restarts)：過多的應用程式重啟可能會導致服務中斷和效能問題。
• 請求執行時間(Request Execution Time)：監控頁面響應時間，以確保使用者獲得快速響應。
• 請求排隊數(Requests Queued)：請求在處理之前在佇列中等待的數量，數值過高通常意味著應用程式無法及時處理請求。
• 請求/秒(Requests/Sec)：此計數器提供了處理請求的速率。

c. ASP.NET應用程式效能計數器

• 管道範例數(Pipeline Instance Count)：活動的請求處理管道數量，這可以幫助識別負載增加。
• 工作程序重啟次數(Worker Process Restarts)：監控過多的工作程序重啟，這可能表明設定問題或不穩定的應用程式。

d. 記憶體效能計數器

• 可用記憶體(Available MBytes)：監控可用的實體記憶體量。
• 頁面生命週期(Page Life Expectancy)：顯示在記憶體中頁面被替換之前的平均壽命，如果數值過低可能需要增加記憶體。

e. CPU效能計數器

• 處理器時間百分比(% Processor Time)：顯示處理器在執行非空閒執行緒工作時所佔用的時間百分比。
• 處理器佇列長度(Processor Queue Length)：顯示處理器佇列中的執行緒數量。如果這個數值經常大於處理器核心數，通常意味著CPU資源緊張。

2. 設定最佳實踐

a. 應用程式池設定

• 定期回收：定期回收應用程式池可以清理死鎖、記憶體漏失等問題，但不應過於頻繁，以免影響效能。
• 限制工作程序數：在多核伺服器上，可以通過增加工作程序數來提高應用程式的處理能力，但過多的工作程序可能會導致上下文切換過多。

b. 輸出快取

• 啟用輸出快取可以減少伺服器執行同樣請求的工作量，從而提升效能。

c. 靜態內容快取

• 為經常被請求的靜態檔案（如圖片、CSS、JavaScript等）設定快取規則，可以有效減輕伺服器壓力。

d. 壓縮

• 啟用動態和靜態內容的壓縮可以減少網路傳輸時間，但會增加CPU負荷。

e. 監控和紀錄檔記錄

• 啟用足夠的監控和紀錄檔記錄來跟蹤效能問題，但過多的紀錄檔記錄可能會影響效能。

f. 安全設定

• 定期更新IIS和作業系統來修復安全漏洞。
• 使用HTTPS來保護資料傳輸。

範例：

假設您發現IIS伺服器上的「每秒請求數(Requests/sec)」持續很高。這可能表明網站流量增大或者有效能瓶頸出現。首先，您應該檢查伺服器的CPU和記憶體使用情況，如果資源使用正常，可能需要檢視具體的應用程式程式碼或資料庫查詢是否有優化空間。如果資源使用率很高，您可能需要考慮擴充套件硬體資源或者通過負載均衡將流量分散到多個伺服器。

另一個例子，如果「請求排隊數(Requests Queued)」持續增加，這可能意味著應用程式池的最大工作程序數設定得過低，或者應用程式程式碼處理請求的效率不高。針對這種情況，您可以提高最大工作程序數，同時檢查和優化程式碼以更高效地處理請求。

通過監控這些關鍵效能計數器並採取相應的最佳實踐，您可以確保IIS伺服器的效能得到最佳化。

2. 關於IIS請求佇列

IIS請求佇列是在應用程式池中處理請求之前，臨時存放請求的地方。當請求的處理速率低於請求到達的速率時，請求就會在佇列中堆積。如果佇列中的請求數量過多，可能會導致使用者體驗變差，甚至請求超時。

監控請求佇列

要監控IIS請求佇列，可以使用Windows效能監視器（Performance Monitor）中的以下效能計數器：

• ASP.NET或ASP.NET應用程式:

  • 請求排隊數(Requests Queued): 顯示當前在所有應用程式池中等待處理的請求數量。
  • 請求排隊峰值(Request Queue Length Peak): 顯示請求佇列長度的最大值。

• Web服務(W3SVC):

  • 當前排隊的請求數(Current Queue Length): 顯示當前在Web服務佇列中等待處理的HTTP請求數量。

優化請求佇列設定

優化IIS請求佇列設定的目標是減少請求在佇列中的等待時間，確保請求能夠快速被處理。這通常可以通過以下方法實現：

1. 增加最大工作程序數:

   • 在應用程式池的高階設定中，可以增加「最大工作程序」數，以允許更多的並行請求處理。這適用於多核伺服器，可以幫助利用額外的CPU資源。

2. 優化應用程式程式碼:

   • 對網站的應用程式程式碼進行效能分析，找出並修復可能導致請求處理緩慢的瓶頸。

3. 調整佇列長度:

   • 在應用程式池的高階設定中，找到「佇列長度」設定，這個值決定了在開始拒絕請求之前，佇列可以累積多少請求。如果伺服器硬體足夠強大，可以適當增加這個值。

4. 調整CPU限制:

   • 如果啟用了CPU限制，確保這些設定不會導致工作程序過早回收，這可能會增加請求在佇列中的時間。

5. 回收策略:

   • 調整應用程式池的回收策略，以避免在高峰時段發生回收，這可能會導致請求暫時無法處理。

6. 啟用自動縮放:

   • 對於雲環境或虛擬化環境，可以根據負載自動調整資源或範例數目。

7. 使用Web園(Web Garden):

   • 在單個應用程式池中設定多個工作程序（稱為Web園）可以幫助並行處理請求，但這可能會增加對談狀態管理的複雜性。

8. 負載均衡:

   • 如果是高流量網站，可以考慮使用負載均衡器分散請求到不同的伺服器上。

範例設定

這是一個修改應用程式池佇列長度的範例：

1. 開啟IIS管理器（Internet Information Services Manager）。
2. 在「連線」面板中，找到並點選「應用程式池」。
3. 在「應用程式池」列表中，選擇您要設定的應用程式池，然後點選「高階設定」（在右側的「操作」面板中）。
4. 在「高階設定」視窗中，找到「佇列長度」設定。預設值通常是1000。
5. 根據您的伺服器效能和應用程式需求調整這個值。例如，如果您的伺服器硬體效能較好，可以嘗試將這個值設定得更高，比如2000。
6. 點選「確定」或「應用」儲存設定。

請注意，調整佇列長度並不總是解決問題的最佳方式，有時候需要更全面的方法來分析和優化整個應用程式和伺服器的效能。

3. 使用windbg分析IIS請求佇列

使用WinDbg (Windows Debugger) 分析IIS請求佇列通常涉及到對IIS工作程序（w3wp.exe）的記憶體轉儲（dump）檔案進行分析。這種分析可以幫助你確定在特定時間點上請求的狀態，找出請求積壓的原因，並且識別效能瓶頸。

以下是使用WinDbg分析IIS請求佇列的一般步驟：

1. 獲取記憶體轉儲

在分析之前，你需要首先獲取IIS工作程序的記憶體轉儲。這可以通過工作管理員、IIS管理器或專用的轉儲工具來完成。例如，你可以使用如下命令通過procdump工具獲取記憶體轉儲：

procdump -ma <PID> -o <output_path>

這裡 <PID> 是IIS工作程序w3wp.exe的程序ID，而 <output_path> 是你想要儲存轉儲檔案的路徑。

2. 設定符號路徑

在WinDbg中，設定正確的符號路徑（symbol path）是很重要的，因為它允許偵錯程式正確解析記憶體轉儲中的地址。你可以將Microsoft的符號伺服器設定為符號路徑：

SRV*your_local_symbol_cache*https://msdl.microsoft.com/download/symbols

在WinDbg中，你可以通過.symfix命令自動設定符號伺服器，或者使用.sympath命令手動設定路徑。

3. 載入記憶體轉儲

在WinDbg中開啟記憶體轉儲檔案。通常是通過 File > Open Crash Dump 選單選項或者使用命令列引數啟動WinDbg。

4. 分析請求佇列

一旦載入了記憶體轉儲，你可以使用各種WinDbg命令來分析請求佇列。一些有用的命令包括：

• !threads：列出所有執行緒，幫助你找到正在處理請求的執行緒。
• !clrstack：如果是.NET應用程式，這個命令可以顯示託管執行緒的託管呼叫堆疊。
• !dumpheap -stat：對於.NET應用程式，這個命令可以顯示記憶體中所有物件的統計資訊。
• !runaway：顯示執行緒的使用者模式執行時間，有助於識別長時間執行的執行緒。

5. 查詢請求相關的物件

在.NET應用程式中，你可能需要查詢與HTTP請求相關的物件，比如HttpContext。你可以使用!dumpheap -type HttpContext命令來找到所有HttpContext物件的記憶體地址，然後用!do <address>命令來檢查每個物件的詳細資訊。

6. 分析特定請求

如果你能夠識別出具體的請求物件，你可以進一步分析這些物件，找出為何請求沒有得到及時處理。這可能涉及到檢視請求的狀態、執行的程式碼路徑以及任何可能的資源鎖定情況。

7. 尋找死鎖和資源爭用

使用!syncblk命令可以查詢.NET應用程式中的鎖定情況，這有助於識別死鎖或資源爭用的問題。

注意事項

• WinDbg是一個非常強大但同時也複雜的工具，需要相當的專業知識來使用。
• 分析記憶體轉儲可能會洩露敏感資訊，請確保遵守隱私和安全規定。
• 確保你有足夠的許可權來獲取和分析記憶體轉儲檔案。

WinDbg的分析能為你提供有關請求處理狀態的深入見解，但它不是實時監控工具。對於實時監控IIS請求佇列的情況，你可能需要依賴效能計數器或者專業的監控軟體。

 

Mex（Managed Execution Environment）是一個用於WinDbg的擴充套件外掛，專門設計用來偵錯.NET應用程式。它提供了一系列的命令來幫助分析.NET應用程式的記憶體轉儲，包括那些託管在IIS中的ASP.NET應用程式。使用Mex外掛可以幫助你更容易地分析IIS請求佇列和相關的託管物件。

如何使用Mex外掛分析IIS請求佇列：

1. 安裝Mex外掛

首先，你需要確保Mex外掛已經被安裝並設定到WinDbg中。通常，這意味著你需要下載Mex外掛，並將其複製到WinDbg的擴充套件目錄中，然後在WinDbg中使用.load命令來載入它。

2. 獲取記憶體轉儲

與使用WinDbg直接分析類似，你首先需要獲取IIS工作程序（w3wp.exe）的記憶體轉儲。你可以使用工作管理員、IIS管理器或工具如procdump來完成這個步驟。

3. 使用WinDbg開啟記憶體轉儲

在WinDbg中開啟記憶體轉儲檔案，通常是通過 File > Open Crash Dump 選單選項。

4. 載入Mex外掛

在WinDbg中，通過.load命令載入Mex擴充套件：

.load <path_to_mex.dll>

5. 設定符號路徑

確保設定了正確的符號路徑，這樣WinDbg才能正確解析轉儲中的符號資訊。

6. 分析請求佇列

使用Mex提供的特殊命令來分析請求佇列。Mex為.NET應用程式提供了一些有用的命令，如：

• !mex.aspxpages：列出所有ASP.NET頁面的狀態，包括它們是否在處理請求。
• !mex.requests：列出當前所有請求的狀態。
• !mex.runaway：找出執行時間最長的執行緒。

7. 深入分析特定請求

如果你發現佇列中有特定的請求被阻塞，你可以使用Mex命令來檢查這些請求的詳細資訊，比如呼叫堆疊、關聯的資源和鎖狀態等。

範例：

例如，如果你想看所有當前的ASP.NET請求，可以使用以下Mex命令：

!mex.requests

這個命令會輸出當前所有請求的列表，包括它們的狀態、正在處理它們的執行緒ID等資訊。

注意事項

• 在分析記憶體轉儲時，你可能需要結合使用不同的命令來獲取完整的資訊。
• 分析可能涉及到敏感資料，請確保符合隱私保護和公司政策。
• Mex外掛和命令在不同版本的.NET Framework和.NET Core上可能有所不同，確保使用與目標應用程式相匹配的工具版本。
• Mex外掛的功能和命令可能會隨時間更新和變化，始終查閱最新的檔案和資源。

使用Mex外掛可以大幅簡化.NET應用程式的記憶體轉儲分析過程，特別是對於IIS託管的ASP.NET應用程式。它可以幫助你更快地識別問題，從而優化IIS請求佇列的效能。