IIS 是由微软公司提供的基于运行 Microsoft Windows 的互联网基本服务，同时也是一种Web（网页）服务组件，其中包括 Web 服务器、FTP 服务器、NNTP 服务器和 SMTP 服务器，分别用于网页浏览、文件传输、新闻服务和邮件发送等方面，它使得在网络（包括互联网和局域网） 上发布信息成了一件很容易的事。
IIS 具有一些既有趣又强大的功能，我们打开文档，会发现一些编辑文字或者编辑文档的界面，会有搜索的功能，这就是 IIS 的作用之一。在一些小地方，或者一些细节之处，IIS具有极其丰富有有作用的细节能力，而编辑文字或者文档中含有搜索功能，也是 IIS 细节的体现。
在IIS Web服务器中，worker processe处理Web请求并提供响应。一台服务器同时运行多个进程。每个worker processe都属于一个应用程序池，且与不同池关联的工作进程不共享该池资源。即使IIS服务器和应用程序是两个单独的实体，但仍有一些指标与这两个指标关联。与worker processe相关的指标，例如应用程序池和响应时间，对于维持IIS服务器和应用程序的健康状况健康状况至关重要。
IIS监控指标
在IIS应用程序中要监控的关键性能指标（KPI）：
网站统计指标：可用性、响应时间、连接状态、字节传输统计
应用程序池统计信息
应用程序性能指标：数据库事务、响应时间、错误与例外
IIS服务器监控
为了避免IIS服务器停机，跟踪服务器数据指标（例如应用程序池统计信息，资源消耗和响应时间）也很重要。
关键性能计数器指标
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资源紧张。设置最佳实践
a. 应用程序池配置
定期回收：定期回收应用程序池可以清理死锁、内存泄漏等问题，但不应过于频繁，以免影响性能。限制工作进程数：在多核服务器上，可以通过增加工作进程数来提高应用程序的处理能力，但过多的工作进程可能会导致上下文切换过多。b. 输出缓存
启用输出缓存可以减少服务器执行同样请求的工作量，从而提升性能。c. 静态内容缓存
为经常被请求的静态文件（如图片、CSS、JavaScript等）配置缓存规则，可以有效减轻服务器压力。d. 压缩
启用动态和静态内容的压缩可以减少网络传输时间，但会增加CPU负荷。e. 监控和日志记录
启用足够的监控和日志记录来跟踪性能问题，但过多的日志记录可能会影响性能。f. 安全设置
定期更新IIS和操作系统来修复安全漏洞。使用HTTPS来保护数据传输。示例：
假设您发现IIS服务器上的“每秒请求数(Requests/sec)”持续很高。这可能表明网站流量增大或者有性能瓶颈出现。首先，您应该检查服务器的CPU和内存使用情况，如果资源使用正常，可能需要查看具体的应用程序代码或数据库查询是否有优化空间。如果资源使用率很高，您可能需要考虑扩展硬件资源或者通过负载均衡将流量分散到多个服务器。
另一个例子，如果“请求排队数(Requests Queued)”持续增加，这可能意味着应用程序池的最大工作进程数设置得过低，或者应用程序代码处理请求的效率不高。针对这种情况，您可以提高最大工作进程数，同时检查和优化代码以更高效地处理请求。
通过监控这些关键性能计数器并采取相应的最佳实践，您可以确保IIS服务器的性能得到最优化。
关于IIS请求队列
IIS请求队列是在应用程序池中处理请求之前，临时存放请求的地方。当请求的处理速率低于请求到达的速率时，请求就会在队列中堆积。如果队列中的请求数量过多，可能会导致用户体验变差，甚至请求超时。
监控请求队列
要监控IIS请求队列，可以使用Windows性能监视器（Performance Monitor）中的以下性能计数器：
ASP.NET或ASP.NET应用程序:
请求排队数(Requests Queued): 显示当前在所有应用程序池中等待处理的请求数量。请求排队峰值(Request Queue Length Peak): 显示请求队列长度的最大值。Web服务(W3SVC):
当前排队的请求数(Current Queue Length): 显示当前在Web服务队列中等待处理的HTTP请求数量。优化请求队列设置
优化IIS请求队列设置的目标是减少请求在队列中的等待时间，确保请求能够快速被处理。这通常可以通过以下方法实现：
增加最大工作进程数:
在应用程序池的高级设置中，可以增加“最大工作进程”数，以允许更多的并发请求处理。这适用于多核服务器，可以帮助利用额外的CPU资源。优化应用程序代码:
对网站的应用程序代码进行性能分析，找出并修复可能导致请求处理缓慢的瓶颈。调整队列长度:
在应用程序池的高级设置中，找到“队列长度”设置，这个值决定了在开始拒绝请求之前，队列可以累积多少请求。如果服务器硬件足够强大，可以适当增加这个值。调整CPU限制:
如果启用了CPU限制，确保这些设置不会导致工作进程过早回收，这可能会增加请求在队列中的时间。回收策略:
调整应用程序池的回收策略，以避免在高峰时段发生回收，这可能会导致请求暂时无法处理。启用自动缩放:
对于云环境或虚拟化环境，可以根据负载自动调整资源或实例数目。使用Web园(Web Garden):
在单个应用程序池中配置多个工作进程（称为Web园）可以帮助并行处理请求，但这可能会增加会话状态管理的复杂性。负载均衡:
如果是高流量网站，可以考虑使用负载均衡器分散请求到不同的服务器上。示例配置
这是一个修改应用程序池队列长度的示例：
打开IIS管理器（Internet Information Services Manager）。在“连接”面板中，找到并点击“应用程序池”。在“应用程序池”列表中，选择您要配置的应用程序池，然后点击“高级设置”（在右侧的“操作”面板中）。在“高级设置”窗口中，找到“队列长度”设置。默认值通常是1000。根据您的服务器性能和应用程序需求调整这个值。例如，如果您的服务器硬件性能较好，可以尝试将这个值设置得更高，比如2000。点击“确定”或“应用”保存设置。请注意，调整队列长度并不总是解决问题的最佳方式，有时候需要更全面的方法来分析和优化整个应用程序和服务器的性能。
使用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请求队列的性能。
暂无评论内容