IIS 是由微軟公司提供的基于運行 Microsoft Windows 的互聯(lián)網(wǎng)基本服務，同時也是一種Web（網(wǎng)頁）服務組件，其中包括 Web 服務器、FTP 服務器、NNTP 服務器和 SMTP 服務器，分別用于網(wǎng)頁瀏覽、文件傳輸、新聞服務和郵件發(fā)送等方面，它使得在網(wǎng)絡（包括互聯(lián)網(wǎng)和局域網(wǎng)） 上發(fā)布信息成了一件很容易的事。

IIS 具有一些既有趣又強大的功能，我們打開文檔，會發(fā)現(xiàn)一些編輯文字或者編輯文檔的界面，會有搜索的功能，這就是 IIS 的作用之一。在一些小地方，或者一些細節(jié)之處，IIS具有極其豐富有有作用的細節(jié)能力，而編輯文字或者文檔中含有搜索功能，也是 IIS 細節(jié)的體現(xiàn)。

在IIS Web服務器中，worker processe處理Web請求并提供響應。一臺服務器同時運行多個進程。每個worker processe都屬于一個應用程序池，且與不同池關(guān)聯(lián)的工作進程不共享該池資源。即使IIS服務器和應用程序是兩個單獨的實體，但仍有一些指標與這兩個指標關(guān)聯(lián)。與worker processe相關(guān)的指標，例如應用程序池和響應時間，對于維持IIS服務器和應用程序的健康狀況健康狀況至關(guān)重要。

IIS監(jiān)控指標

在IIS應用程序中要監(jiān)控的關(guān)鍵性能指標（KPI）：

網(wǎng)站統(tǒng)計指標：可用性、響應時間、連接狀態(tài)、字節(jié)傳輸統(tǒng)計

應用程序池統(tǒng)計信息

應用程序性能指標：數(shù)據(jù)庫事務、響應時間、錯誤與例外 

IIS服務器監(jiān)控  

為了避免IIS服務器停機，跟蹤服務器數(shù)據(jù)指標（例如應用程序池統(tǒng)計信息，資源消耗和響應時間）也很重要。

關(guān)鍵性能計數(shù)器指標

a. Web服務（W3SVC）性能計數(shù)器

• 當前連接數(shù)(Current Connections)：顯示當前所有HTTP連接的數(shù)量。過高的數(shù)值可能表明網(wǎng)站流量過大或連接無法及時釋放。
• 每秒請求數(shù)(Requests/sec)：顯示每秒鐘收到的HTTP請求的數(shù)量。這可以幫助您了解網(wǎng)站的流量。
• 匿名用戶/秒(Anonymous Users/sec) 和 非匿名用戶/秒(NonAnonymous Users/sec)：監(jiān)控匿名和已認證用戶的請求數(shù)有助于了解安全需求。
• ISAPI擴展請求(ISAPI Extension Requests/sec)：如果您使用ISAPI擴展，監(jiān)控此計數(shù)器有助于識別性能瓶頸。

b. ASP.NET性能計數(shù)器

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

c. ASP.NET應用程序性能計數(shù)器

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

d. 內(nèi)存性能計數(shù)器

• 可用內(nèi)存(Available MBytes)：監(jiān)控可用的物理內(nèi)存量。
• 頁面生命周期(Page Life Expectancy)：顯示在內(nèi)存中頁面被替換之前的平均壽命，如果數(shù)值過低可能需要增加內(nèi)存。

e. CPU性能計數(shù)器

• 處理器時間百分比(% Processor Time)：顯示處理器在執(zhí)行非空閑線程工作時所占用的時間百分比。
• 處理器隊列長度(Processor Queue Length)：顯示處理器隊列中的線程數(shù)量。如果這個數(shù)值經(jīng)常大于處理器核心數(shù)，通常意味著CPU資源緊張。

設(shè)置最佳實踐

a. 應用程序池配置

• 定期回收：定期回收應用程序池可以清理死鎖、內(nèi)存泄漏等問題，但不應過于頻繁，以免影響性能。
• 限制工作進程數(shù)：在多核服務器上，可以通過增加工作進程數(shù)來提高應用程序的處理能力，但過多的工作進程可能會導致上下文切換過多。

b. 輸出緩存

• 啟用輸出緩存可以減少服務器執(zhí)行同樣請求的工作量，從而提升性能。

c. 靜態(tài)內(nèi)容緩存

• 為經(jīng)常被請求的靜態(tài)文件（如圖片、CSS、JavaScript等）配置緩存規(guī)則，可以有效減輕服務器壓力。

d. 壓縮

• 啟用動態(tài)和靜態(tài)內(nèi)容的壓縮可以減少網(wǎng)絡傳輸時間，但會增加CPU負荷。

e. 監(jiān)控和日志記錄

• 啟用足夠的監(jiān)控和日志記錄來跟蹤性能問題，但過多的日志記錄可能會影響性能。

f. 安全設(shè)置

• 定期更新IIS和操作系統(tǒng)來修復安全漏洞。
• 使用HTTPS來保護數(shù)據(jù)傳輸。

示例：

假設(shè)您發(fā)現(xiàn)IIS服務器上的“每秒請求數(shù)(Requests/sec)”持續(xù)很高。這可能表明網(wǎng)站流量增大或者有性能瓶頸出現(xiàn)。首先，您應該檢查服務器的CPU和內(nèi)存使用情況，如果資源使用正常，可能需要查看具體的應用程序代碼或數(shù)據(jù)庫查詢是否有優(yōu)化空間。如果資源使用率很高，您可能需要考慮擴展硬件資源或者通過負載均衡將流量分散到多個服務器。

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

通過監(jiān)控這些關(guān)鍵性能計數(shù)器并采取相應的最佳實踐，您可以確保IIS服務器的性能得到最優(yōu)化。

關(guān)于IIS請求隊列

IIS請求隊列是在應用程序池中處理請求之前，臨時存放請求的地方。當請求的處理速率低于請求到達的速率時，請求就會在隊列中堆積。如果隊列中的請求數(shù)量過多，可能會導致用戶體驗變差，甚至請求超時。

監(jiān)控請求隊列

要監(jiān)控IIS請求隊列，可以使用Windows性能監(jiān)視器（Performance Monitor）中的以下性能計數(shù)器：

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

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

• Web服務(W3SVC):

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

優(yōu)化請求隊列設(shè)置

優(yōu)化IIS請求隊列設(shè)置的目標是減少請求在隊列中的等待時間，確保請求能夠快速被處理。這通?？梢酝ㄟ^以下方法實現(xiàn)：

• 增加最大工作進程數(shù):

  • 在應用程序池的高級設(shè)置中，可以增加“最大工作進程”數(shù)，以允許更多的并發(fā)請求處理。這適用于多核服務器，可以幫助利用額外的CPU資源。

• 優(yōu)化應用程序代碼:

  • 對網(wǎng)站的應用程序代碼進行性能分析，找出并修復可能導致請求處理緩慢的瓶頸。

• 調(diào)整隊列長度:

  • 在應用程序池的高級設(shè)置中，找到“隊列長度”設(shè)置，這個值決定了在開始拒絕請求之前，隊列可以累積多少請求。如果服務器硬件足夠強大，可以適當增加這個值。

• 調(diào)整CPU限制:

  • 如果啟用了CPU限制，確保這些設(shè)置不會導致工作進程過早回收，這可能會增加請求在隊列中的時間。

• 回收策略:

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

• 啟用自動縮放:

  • 對于云環(huán)境或虛擬化環(huán)境，可以根據(jù)負載自動調(diào)整資源或?qū)嵗龜?shù)目。

• 使用Web園(Web Garden):

  • 在單個應用程序池中配置多個工作進程（稱為Web園）可以幫助并行處理請求，但這可能會增加會話狀態(tài)管理的復雜性。

• 負載均衡:

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

示例配置

這是一個修改應用程序池隊列長度的示例：

• 打開IIS管理器（Internet Information Services Manager）。
• 在“連接”面板中，找到并點擊“應用程序池”。
• 在“應用程序池”列表中，選擇您要配置的應用程序池，然后點擊“高級設(shè)置”（在右側(cè)的“操作”面板中）。
• 在“高級設(shè)置”窗口中，找到“隊列長度”設(shè)置。默認值通常是1000。
• 根據(jù)您的服務器性能和應用程序需求調(diào)整這個值。例如，如果您的服務器硬件性能較好，可以嘗試將這個值設(shè)置得更高，比如2000。
• 點擊“確定”或“應用”保存設(shè)置。

請注意，調(diào)整隊列長度并不總是解決問題的最佳方式，有時候需要更全面的方法來分析和優(yōu)化整個應用程序和服務器的性能。

使用windbg分析IIS請求隊列

使用WinDbg (Windows Debugger) 分析IIS請求隊列通常涉及到對IIS工作進程（w3wp.exe）的內(nèi)存轉(zhuǎn)儲（dump）文件進行分析。這種分析可以幫助你確定在特定時間點上請求的狀態(tài)，找出請求積壓的原因，并且識別性能瓶頸。

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

1. 獲取內(nèi)存轉(zhuǎn)儲

在分析之前，你需要首先獲取IIS工作進程的內(nèi)存轉(zhuǎn)儲。這可以通過任務管理器、IIS管理器或?qū)Ｓ玫霓D(zhuǎn)儲工具來完成。例如，你可以使用如下命令通過procdump工具獲取內(nèi)存轉(zhuǎn)儲：

procdump -ma <PID> -o <output_path>

這里 <PID> 是IIS工作進程w3wp.exe的進程ID，而 <output_path> 是你想要保存轉(zhuǎn)儲文件的路徑。

2. 設(shè)置符號路徑

在WinDbg中，設(shè)置正確的符號路徑（symbol path）是很重要的，因為它允許調(diào)試器正確解析內(nèi)存轉(zhuǎn)儲中的地址。你可以將Microsoft的符號服務器設(shè)置為符號路徑：

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

在WinDbg中，你可以通過.symfix命令自動設(shè)置符號服務器，或者使用.sympath命令手動設(shè)置路徑。

3. 加載內(nèi)存轉(zhuǎn)儲

在WinDbg中打開內(nèi)存轉(zhuǎn)儲文件。通常是通過 File > Open Crash Dump 菜單選項或者使用命令行參數(shù)啟動WinDbg。

4. 分析請求隊列

一旦加載了內(nèi)存轉(zhuǎn)儲，你可以使用各種WinDbg命令來分析請求隊列。一些有用的命令包括：

• !threads：列出所有線程，幫助你找到正在處理請求的線程。
• !clrstack：如果是.NET應用程序，這個命令可以顯示托管線程的托管調(diào)用堆棧。
• !dumpheap -stat：對于.NET應用程序，這個命令可以顯示內(nèi)存中所有對象的統(tǒng)計信息。
• !runaway：顯示線程的用戶模式執(zhí)行時間，有助于識別長時間運行的線程。

5. 查找請求相關(guān)的對象

在.NET應用程序中，你可能需要查找與HTTP請求相關(guān)的對象，比如HttpContext。你可以使用!dumpheap -type HttpContext命令來找到所有HttpContext對象的內(nèi)存地址，然后用!do <address>命令來檢查每個對象的詳細信息。

6. 分析特定請求

如果你能夠識別出具體的請求對象，你可以進一步分析這些對象，找出為何請求沒有得到及時處理。這可能涉及到查看請求的狀態(tài)、執(zhí)行的代碼路徑以及任何可能的資源鎖定情況。

7. 尋找死鎖和資源爭用

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

注意事項

• WinDbg是一個非常強大但同時也復雜的工具，需要相當?shù)膶I(yè)知識來使用。
• 分析內(nèi)存轉(zhuǎn)儲可能會泄露敏感信息，請確保遵守隱私和安全規(guī)定。
• 確保你有足夠的權(quán)限來獲取和分析內(nèi)存轉(zhuǎn)儲文件。

WinDbg的分析能為你提供有關(guān)請求處理狀態(tài)的深入見解，但它不是實時監(jiān)控工具。對于實時監(jiān)控IIS請求隊列的情況，你可能需要依賴性能計數(shù)器或者專業(yè)的監(jiān)控軟件。

Mex（Managed Execution Environment）是一個用于WinDbg的擴展插件，專門設(shè)計用來調(diào)試.NET應用程序。它提供了一系列的命令來幫助分析.NET應用程序的內(nèi)存轉(zhuǎn)儲，包括那些托管在IIS中的ASP.NET應用程序。使用Mex插件可以幫助你更容易地分析IIS請求隊列和相關(guān)的托管對象。

如何使用Mex插件分析IIS請求隊列：

1. 安裝Mex插件

首先，你需要確保Mex插件已經(jīng)被安裝并配置到WinDbg中。通常，這意味著你需要下載Mex插件，并將其復制到WinDbg的擴展目錄中，然后在WinDbg中使用.load命令來加載它。

2. 獲取內(nèi)存轉(zhuǎn)儲

與使用WinDbg直接分析類似，你首先需要獲取IIS工作進程（w3wp.exe）的內(nèi)存轉(zhuǎn)儲。你可以使用任務管理器、IIS管理器或工具如procdump來完成這個步驟。

3. 使用WinDbg打開內(nèi)存轉(zhuǎn)儲

在WinDbg中打開內(nèi)存轉(zhuǎn)儲文件，通常是通過 File > Open Crash Dump 菜單選項。

4. 加載Mex插件

在WinDbg中，通過.load命令加載Mex擴展：

.load <path_to_mex.dll>

5. 設(shè)置符號路徑

確保設(shè)置了正確的符號路徑，這樣WinDbg才能正確解析轉(zhuǎn)儲中的符號信息。

6. 分析請求隊列

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

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

7. 深入分析特定請求

如果你發(fā)現(xiàn)隊列中有特定的請求被阻塞，你可以使用Mex命令來檢查這些請求的詳細信息，比如調(diào)用堆棧、關(guān)聯(lián)的資源和鎖狀態(tài)等。

示例：

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

!mex.requests

這個命令會輸出當前所有請求的列表，包括它們的狀態(tài)、正在處理它們的線程ID等信息。

注意事項

• 在分析內(nèi)存轉(zhuǎn)儲時，你可能需要結(jié)合使用不同的命令來獲取完整的信息。
• 分析可能涉及到敏感數(shù)據(jù)，請確保符合隱私保護和公司政策。
• Mex插件和命令在不同版本的.NET Framework和.NET Core上可能有所不同，確保使用與目標應用程序相匹配的工具版本。
• Mex插件的功能和命令可能會隨時間更新和變化，始終查閱最新的文檔和資源。

使用Mex插件可以大幅簡化.NET應用程序的內(nèi)存轉(zhuǎn)儲分析過程，特別是對于IIS托管的ASP.NET應用程序。它可以幫助你更快地識別問題，從而優(yōu)化IIS請求隊列的性能。

到此這篇關(guān)于中間件IIS監(jiān)控指標、設(shè)置和Windbg|Mex調(diào)試分析的文章就介紹到這了,更多相關(guān)IIS監(jiān)控指標和調(diào)試內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論