排查页面响应缓慢和挂起问题

适用于： Internet Information Services（IIS）、ASP.NET、ASP.NET Core

本文提供了有关如何收集和分析数据的指南，以排查页面响应缓慢和挂起问题。

确定正确的故障排除指南

页面缓慢和挂起可能伴随着以下一个或多个条件。 请务必确定这些条件，以便可以相应地集中故障排除。 确定其中哪一种最详细地描述了要进行故障排除的问题，并按照相应的故障排除指南进行作。

• 缓慢或仅挂起，CPU 和内存使用率正常

  排查页面响应缓慢和挂起

• 慢速或挂起伴随着高 CPU

  • 关注速度缓慢 - 排查页面响应缓慢和挂起
  • 专注于高 CPU - IIS 应用程序池中的高 CPU 故障排除

• 慢速或挂起伴随着高内存

  • 关注速度缓慢 - 排查页面响应缓慢和挂起
  • 专注于高内存 - 高内存消耗问题的概述

• 慢速或挂起伴随着高内存和高 CPU

  当存在所有三个条件时，请使用 高内存消耗问题的概述。 这是因为在这些情况下 CPU 通常较高是由于内存过高，而当内存和 CPU 都很高时，这会导致速度缓慢。

• 仅高 CPU

  排查 IIS 应用程序池中的高 CPU 问题

• 仅高内存

  内存消耗问题概述

数据收集

下面列出了用于收集缓慢页面响应或挂起情况的有用数据。 并非每个问题都需要所有这些数据。 可以根据情况收集数据。

• IIS 日志捕获器数据
  • IIS 和 ASP.NET 配置文件
  • IIS Web 日志（W3SVC 日志）
  • 事件日志（系统、应用程序和安全性）
• Fiddler 跟踪或 Microsoft Edge HAR 跟踪
• 失败的请求跟踪（FREB）日志
• 完全用户模式进程转储
• 其他数据
• 时间触发器量
• 使用 DebugDiag 手动生成内存转储
• 配置 FREB 以使用 ProcDump.exe 触发内存转储

IIS 日志捕获器

IIS 日志捕获器一次收集各种历史日志和配置数据，包括 IIS Web 日志，这对于诊断慢页面响应问题特别有用。 它还收集所有 .config 文件，这有助于了解服务器上的不同 Web 应用程序及其配置方式。 如果已配置 FREB 日志记录，则 IIS 日志捕获器数据中也包含 FREB 日志。 IIS 日志捕获器还会收集系统和应用程序事件日志。

下载 IIS 日志捕获器 工具，并按照 说明使用它收集数据。

配置文件

applicationhost.config 和 web.config 作为 IIS 日志捕获器数据的一部分收集。 这些文件有助于了解 IIS 的配置以及服务器上的单个 Web 应用程序。

如果 IIS 日志捕获器工具不自动收集配置文件，则需要手动收集这些文件。

applicationhost.config 文件位于 c：\windows\system32\inetsrv\config\。 web.config 文件位于每个应用程序的根目录中。 例如，对于默认网站的应用程序，web.config 文件位于 c：\inetpub\wwwroot中。 应用程序的根目录可能位于文件系统的任意位置。 若要标识特定站点的根目录，请检查 站点 及其 physicalPath 属性的 applicationhost.config 文件，或查看 IIS 管理器中的设置。

IIS Web 日志 （W3SVC 日志）

从发生速度缓慢的某个时间收集 IIS 日志。 这可能有助于确认花费时间的字段反映速度缓慢。 它还有助于缩小响应缓慢的页面或页面的范围。

如果 IIS 日志捕获器工具不会自动收集 Web 日志，则需要手动收集它们。

默认情况下，这些日志位于 c：\inetpub\logs\logfiles。 每个站点都有自己的目录 W3SVC#，其中 # 是 SiteID。 但是，日志位置是可自定义的。 若要查找自定义日志位置，可能需要查看 logFile 的 applicationhost.config 文件，以及指定日志存储位置的 目录 设置。

Windows 系统、应用程序和安全事件日志

这些收集是 IIS 日志捕获器数据的一部分。 尽管在排查页面响应缓慢和挂起问题时通常不使用事件日志，但最佳做法是继续收集它们，因为它们可能会在故障排除时使用。

如果 IIS 日志捕获器工具不自动收集事件日志，则需要手动收集它们。

直接从事件查看器收集事件日志。 将它们另存为 .evtx 文件，并在自己的服务器上事件查看器中查看它们。

Fiddler 工具跟踪或Microsoft Edge HAR 跟踪

这些跟踪中的时间线视图可能有助于缩小 Web 应用程序中的页面或页面速度较慢的范围。 这有助于仅收集慢速页面的 FREB 日志。

Fiddler Classic 是充当浏览器代理的第三方浏览器扩展。 Fiddler 在打开数据后立即开始收集数据。 若要使用 Fiddler Classic 收集 SSL 加密请求的跟踪，请执行以下步骤：

1. 下载并安装 Fiddler Classic。
2. 打开 Fiddler 经典版，选择 工具>选项>HTTPS，然后选择 “捕获 HTTPS CONNECT”和“解密 HTTPS 流量”复选框。
3. 选择“确定”。
4. 在运行 Fiddler 时重现速度缓慢。
5. 选择 文件>保存>所有会话 以将所有会话另存为 .saz 文件。

Microsoft Edge 或 Chrome 浏览器可以直接收集 HAR 跟踪。 若要收集 HAR 跟踪，请执行以下步骤：

1. 打开浏览器，然后选择 F12 打开开发人员工具。
2. 选择 网络>保留日志。
3. 重现缓慢问题。
4. 选择“导出 HAR，将跟踪另存为 .HAR 文件。 .HAR 文件可以导入到 Microsoft Edge 或 Chrome 中，以供以后查看。

失败的请求跟踪 （FREB） 日志

FREB 日志可帮助确定 IIS 模块处理请求所花费的时间最长。 它可以识别身份验证或应用程序代码本身的缓慢性。

失败的请求跟踪是 IIS 模块。 安装跟踪模块时，可以使用它。 可以从服务器管理器或运行以下 PowerShell 命令安装跟踪：

Add-WindowsFeature -Name Web-Http-Tracing 

在配置 FREB 规则之前，请检查 W3SVC 日志以识别需要很长时间才能完成的请求。 识别使用 cs-uri-stem 和 time-taken 字段速度缓慢的各个页面请求。

• 如果可以识别一些速度缓慢的特定页面，为特定页面或页面创建 FREB 规则。 如果为特定页面创建规则，请不要在 FREB 规则中使用时间。 请改用 W3SVC 日志中的状态代码。

• 如果无法标识创建 FREB 规则的特定页面，则可以使用所有内容，改为指定 FREB 规则 中花费的时间，从而记录完成时间超过指定时间的所有请求。

  注释

  此方法可能会提供误报。 另请注意，根据所花费的时间创建 FREB 日志时，日志将在请求达到指定的时间时结束。 如果指定的时间太短，则无法确定速度缓慢的发生位置。

此问题正在进行、易于重现或频繁出现

注释

由某些状态代码规则触发的 FREB 日志提供在请求生存期内沿 IIS 管道发生的所有模块的视图，以及每个模块花费的时间。

由特定时间花费的值规则（例如 20 秒）触发的 FREB 日志仅显示该值的信息，这意味着此请求超出此时间的任何内容都不会在日志中可用。

• 如果在某个延迟后收到响应（例如 30 秒），请按照以下步骤诊断问题：

  1. 检查收到的响应的状态代码。

     使用浏览器开发人员工具或 IIS 日志来确定延迟响应的状态代码。

  2. 根据步骤 1 中的状态代码配置 FREB。

  3. 查看生成的 FREB 以了解哪个模块导致速度缓慢。

     如果不熟悉如何解释 FREB，请参阅 读取 FREB 日志、失败的请求跟踪：IIS 请求处理管道执行。

  如果发现某些第三方模块导致速度缓慢，请联系第三方调查问题。 但是，如果速度缓慢是由于应用程序代码造成的，则需要收集内存转储以进一步调查。

• 如果未收到任何响应（完全挂起），或者在很长一段时间后收到，请按照以下步骤诊断问题：

  1. 基于特定时间的规则配置 FREB。

     为 FREB 日志设置的时间阈值应高于响应的正常时间或可接受的时间。 如果知道响应需要 10 秒是正常的，则配置 20 秒或 30 秒等更高数字的 FREB。

  2. 继续执行上述相同的分析步骤。

此问题是间歇性的或难以重现的

如果问题间歇性或难以重现，则等待它再次发生只是为了收集 FREB 日志可能会效率低下。 此问题可能需要数周或几个月才能重新出现，如果 FREB 日志不足，则需要等待再次收集内存转储。 为了避免这种延迟，建议在第一次出现问题时生成内存转储。

如果请求通常需要毫秒，但偶尔需要 1 或几秒钟时间，则调查这种速度可能会很困难。 在此类缓慢期间生成内存转储可能并不可行，因为：

• 调试器会增加开销，这可能会导致一定程度的缓慢。
• 原始速度缓慢和开销可能会重叠。
• 在请求生存期内生成多个内存转储在一开始可能是不可能的。

可以 改为使用 PerfView 收集 ETW 跟踪。 但是，如果时间太分散，而不是专注于特定作，则调查可能仍然非常有限。

始终检查 IIS 日志中是否有非常慢的请求并对其进行故障排除，因为这可能会间接解决更慢的问题。

根据花费的时间收集 FREB 日志的详细步骤

重要

若要配置 FREB 日志，请确保 为 IIS 安装跟踪 角色服务。

若要安装 IIS 的 跟踪 角色服务，请执行以下步骤：

1. 打开服务器管理器，然后选择“管理>添加角色和功能”。
2. 在“添加角色和功能向导”窗口中，选择“下一步”，直到到达“服务器角色”页。
3. 展开 Web 服务器（IIS）>Web 服务器>运行状况和诊断，然后选择“跟踪”复选框。
4. 为后续步骤选择“ 下一步 ”，然后选择“ 安装”。

安装跟踪角色服务后，请按照以下步骤捕获 FREB：

1. 打开“运行”命令窗口。

2. 启动“inetmgr”。

3. 在 IIS 管理器的 “连接 ”窗格中，展开计算机名称，展开 “站点”，然后选择目标网站。

   

4. 双击“失败请求跟踪规则”。

   

5. 在 “作 ”窗格中，选择“ 添加”。

6. 在“添加失败的请求跟踪规则”向导的“指定内容到跟踪”页上，选择“下一步的所有内容>”。

   

7. 在 定义跟踪条件 页上，根据注意到请求或页面所用的时间更新 时间 字段，然后选择 下一。

   例如，如果请求通常需要不到一秒，但现在需要 20 秒，请在 “花费的时间”字段中键入 20。

8. 在“选择跟踪提供程序”页上的“提供程序”下，选中所有复选框。 在“区域”下，确保为每个提供程序选中所有复选框。 在“详细程度”下，选择“详细”。 选择“完成”。

9. 为站点启用 失败的请求跟踪 并配置日志文件目录：

   1. 在 “连接 ”窗格中，展开计算机名称，展开 “站点”，然后选择“ 默认网站”。

   2. 在“作”窗格中的“配置”下，选择“失败的请求跟踪”。

      

   3. 在“编辑网站失败请求跟踪设置”对话框中，选中“启用”复选框，将目录字段设置为 %SystemDrive%\inetpub\logs\FailedReqLogFiles，并将最大跟踪文件数设置为 1000。

      

   4. 选择“确定”。

完全用户模式进程转储

当请求速度缓慢或挂起时，一系列进程转储（2-4）可能会告诉你应用程序中的哪个方法调用速度较慢。 它还可能表示远程请求远程 Web 服务或后端数据库的延迟。

此问题易于重现

如果问题可以重现或当前发生，则可以捕获托管应用池的工作进程的多个手动转储。

尝试将空间转储相隔约 30 秒，但请注意总速度缓慢。 如果速度缓慢的总周期较短（例如，总共 20 到 30 秒），空间会更紧密地转储，以适应慢速周期内至少两个转储。

（可选）可以使用 ProcDump，尤其是在不能在服务器上安装 DebugDiag 或安装时需要它。

如果问题更间歇性，请考虑捕获 FREB 跟踪和转储。 或者，如果使用 ProcDump 更简单，请按照 配置 FREB 中的步骤，使用 ProcDump.exe 部分触发内存转储（为花费的时间而不是状态代码设置 FREB）。

问题不容易重现

如果问题不容易重现，则可以使用 FREB 规则根据花费的时间生成转储。 有关详细信息，请参阅 使用 FREB 在长时间运行的请求生成转储。

重要

设置 FREB 的时间时，根据响应速度缓慢调整触发时间。 这可确保仅捕获有问题的请求，并最大程度地减少误报。

检测到死锁挂起

谨慎

• 如果速度缓慢伴随着高 CPU，请避免在 CPU 使用率非常高（例如，>=95）时收集日志，因为这可能会使服务器因 CPU 资源不足而挂起或无法收集日志。

• 如果手动收集日志，请确保 CPU 使用率低于阈值，以便 RDP 访问服务器。 如果需要，请尝试在收集日志之前回收应用程序池，但请注意对现有请求的影响，并向客户解释这一点。

• 如果 CPU 在回收后的几秒钟内达到此类值，请考虑减少针对进程的负载（无论是负载测试还是生产负载）。

• 同样，如果速度缓慢伴随着高内存，请尝试避免在高 w3wp.exe 内存消耗（如尽可能 >10GB）（或总服务器内存消耗量 > 95%）时收集内存转储。 如果问题可以在较低的内存中重现，请考虑回收应用池或减少负载（如前所述）。

• 请勿使用任务管理器收集转储。 虽然有时生成的转储很有用，但在许多情况下，它们并不有用。 像 DebugDiag 和 Procdump 这样的工具更加专业，对托管代码的理解更深入，能够提供与 ASP.NET 应用相关的更详细的信息。 此外，这两个工具负责处理进程位，无需担心。 而在任务管理器中，如果任务管理器 64 位进程用于生成 32 位进程的转储，反之亦然，则转储是毫无用的。

其他数据

根据需要收集以下数据选项：

• PerfView 跟踪

  PerfView 可以帮助隔离 Web 应用程序本身中性能缓慢的问题。 PerfView 跟踪是在速度缓慢期间收集的。 这些跟踪显示速度缓慢的各个方法或函数。

• 网络跟踪

  跟踪缓慢的页面响应和与网络问题关联的挂起时，网络跟踪非常有用。

• 性能监视器日志

  跟踪页面响应缓慢且与 CPU 使用率高或内存使用率高相关的挂起时，PerfMon 日志记录非常有用。

时间触发器量

若要解决此问题，必须确定触发内存转储生成的适当时间值。

这涉及到了解 Internet Information Services （IIS） 日志的响应时间，在此期间存在问题以及问题不存在的时间。

若要标识适当的时间触发器，请执行以下步骤：

1. 查看 IIS 日志：

   分析各种时间范围内的 IIS 日志，以观察响应时间。 确定正常情况下预期的响应时间。

2. 确定响应时间差异：

   出现问题时，请注意最小、最大和最常见的响应时间。

3. 设置触发目标：

   目标是在慢速请求处于活动状态期间至少生成两个连续内存转储。

   例如，如果响应通常需要 10 秒，请专注于超过此持续时间的响应时间。 如果问题导致响应时间延长到 60 秒或更多，请按 30、40 和 50 秒等间隔捕获内存转储。

4. 避免误报：

   请务必不要在 11 或 12 秒等稍微更高的时间启动内存转储，因为这可能会导致误报。 目标是在有问题的时间段内捕获转储，而无需过早地结束请求。

5. 确定转储的计时：

   请确保在请求生存期结束时不会触发转储，因为请求可能在生成后续转储之前完成。

6. 评估最频繁的慢响应：

   如果未频繁出现最慢的响应时间，请关注 IIS 日志中观察到的最常见慢响应时间。

注释

• 可能需要多次尝试才能获取一组有用的内存转储。
• 确保你选择的驱动器上有足够的空间来保存生成的内存转储。 每个内存转储的大小与生成时的进程大小相同。 因此，例如，如果在生成内存转储时进程的大小为 1GB，则生成三个转储需要 4GB 的空间。

使用 DebugDiag 手动生成内存转储

如果可以触发慢速请求并知道在开始生成内存转储之前暂停多长时间，请执行以下步骤。

如果无法触发请求（例如，客户端是移动应用，你无权访问它，并且问题不能只是从浏览器重现），但通过某种方式知道问题何时发生，请按照以下步骤确认速度缓慢：

1. 按照以下步骤启用请求监视器：

   1. 打开服务器管理器。
   2. 选择右上角的 管理，然后选择 添加角色和功能>下一。
   3. 在“添加角色和功能向导” 窗口中，选择 基于角色或基于功能的安装>下一。
   4. 从服务器池中选择要配置的服务器。
   5. 在 选择服务器角色 部分中，展开 Web 服务器（IIS）>Web 服务器>运行状况和诊断。
   6. 在 运行状况和诊断下，选中 请求监视器 复选框。
   7. 选择 下一>下一>安装 以启用请求监视器功能。

安装完成后，可能需要重启 IIS。 可以通过打开命令提示符并键入 iisreset.exe来重启它。

1. 打开 IIS 管理器，然后选择左侧的服务器名称。
2. 双击“ 工作进程”。
3. 双击有问题的应用程序池，然后选择 时间已用 列。

有关详细信息，请参阅 使用 RSCA 来帮助你了解 IIS 服务器请求。

如果确认速度缓慢，请手动执行内存转储。 但是，这不能保证转储在其生存期内包含相同的有问题的请求，因此，如果手动执行转储（即使自动执行，有时需要多次尝试），也可能需要多次尝试。

若要手动执行内存转储，请执行以下步骤：

1. 下载并安装 调试诊断工具 v2 Update 3.2。

2. 发生内存泄漏时，从“开始”菜单打开 DebugDiag 2 集合：

   

   注释

   如果需要更改生成转储的路径，请选择“工具>选项和设置手动用户转储文件夹”>以更改它。

3. 选择“进程”选项卡。

4. 找到具有有问题的应用程序的“进程 ID”列的 w3wp 进程。

   替换为<PID>面临高内存问题的w3wp.exe进程的实际 PID。 有关如何获取 PID 的详细信息，请按照“识别高内存使用率”中的步骤操作。

5. 右键单击 w3wp 进程，选择“创建 Userdump 系列”，并设置以下选项（根据需要调整数字）。 不要选择“ 保存并关闭”。

   

6. 重现速度缓慢，并在请求缓慢时选择“保存 & 关闭”。

   如果不知道如何重现慢速，并且速度很快且频繁，请等待缓慢开始，然后再选择 “保存 & 关闭”。 选择“保存 & 关闭 后，转储将立即开始收集。

配置 FREB 以使用 ProcDump.exe 触发内存转储

本部分提供有关如何配置失败请求跟踪规则（FREB）以使用 ProcDump.exe触发内存转储的分步说明。 当无法在服务器上安装某些应用程序（如 DebugDiag）时，此方法特别有用。

按照以下步骤将 FREB 配置为运行自定义作（如 ProcDump.exe）以在满足特定规则时生成内存转储。

1. 在适当的请求时间值配置 FREB。 请确保设置一个采用时间的规则，而不是状态代码。

2. 按照以下步骤启用自定义作：

   1. 打开 IIS 管理器，然后选择屏幕左侧的服务器名称。

   2. 双击 配置编辑器 图标。

   3. 导航到 applicationHost/sites 部分，然后选择 ...（省略号）按钮。

      

   4. 选择已将“失败跟踪规则”添加到的站点。

      

   5. 将 customActionsEnabled 设置为 True。

   6. 下载 ProcDump，并将可执行文件复制到 C：\procDump 路径。 在 C：\ 驱动器下创建名为 myDumps 的目录。

      警告

      必须在不包含空格的文件夹路径中放置 ProcDump 工具。 否则，无法通过 FREB 执行 ProcDump。 例如，C：\procDump 是一个很好的路径文件夹，而 C：\Process Dump 则不是。

3. 指定 ProcDump 的自定义作：

   1. 在服务器或站点级别指定作，然后选择 ... 按钮，如以下屏幕截图所示：

      

   2. 选择 “作”窗格下的“添加”链接，并填写属性，如以下屏幕截图所示：

      

      • CustomActionExe：将值设置为 ProcDump 可执行文件的路径。

      • customActionParams：将值设置为 -accepteula -ma %1% C:\myDumps -n 3。

        此命令生成三个连续转储，间隔 10 秒。 如果需要更改间距，请添加 -s 后跟秒数。

数据分析

本部分提供了有关如何使用各种工具来分析数据以诊断和排查 IIS 中缓慢的页面响应和挂起问题的指南。

IIS Web 日志 （W3SVC 日志）

分析 W3SVC 日志时，有几个目标。

• 验证请求是否正在缓慢执行。 查看所花费的时间值，确认请求的执行时间。
• 确定哪些页面正在缓慢执行。 结合时间，使用 cs-uri-stem 值按名称标识慢页。

所花费的时间以毫秒为单位记录。 1000 毫秒 = 1 秒。 查找完成时间超过 30 秒的请求时，查找超过 30,000 毫秒的耗时值。

有两种工具可用于分析 W3SVC 日志，Excel 和 Log Parser 2.2。

使用 Excel 分析单个 W3SVC 日志

若要使用 Excel 分析单个 W3SVC 日志，请执行以下步骤：

1. 在 Excel 中打开 W3SVC 日志。
2. 选择并删除前三行（所有行都应以 # 符号开头）。 请确保保留以 #Fields开头的行。
3. 选择列 A。在 数据 功能区中，选择 文本到列。
4. 在 将文本转换为列向导中，选择 分隔符>下一。
5. 在 分隔符中，选中 空格 复选框并清除任何其他检查，然后选择 完成。
6. 选择单元格 A1，右键单击它，然后从上下文菜单中选择 删除。
7. 出现提示时，选择 向左移动单元格。
8. 选择行 1。 在 数据 功能区中，选择 筛选器。

现在，可以使用筛选器来确定大于所需秒数的所有请求的时间。

使用日志分析器分析多个 W3SVC 日志

如果有多个日志进行分析或 Excel 无法打开的单个日志文件，请考虑使用 Log Parser 2.2（Microsoft下载中心）。 它是一种功能强大的工具，可用于运行 SQL 样式的查询，以便从各种类型的日志文件（包括 W3SVC 日志）中提取数据。

若要使用 Log Parser 2.2，请执行以下步骤：

1. 下载并安装 Log Parser 2.2（Microsoft下载中心）。

2. 打开命令提示符并导航到日志分析器安装目录。

3. 在 命令提示符 窗口中运行查询。 下面是一些查询示例：

   • 首要请求的页面

     "C:\Program Files (x86)\Log Parser 2.2\logparser.exe" -i:W3C -o:CSV "SELECT TOP 100 cs-uri-stem as URL-Requested, COUNT(*) AS Num-Requests, MAX(time-taken) As Max-Time-Taken, MIN(time-taken) As Min-Time-Taken, Avg(time-taken) As Average-Time-Taken FROM *.log GROUP BY URL-Requested ORDER By Num-Requests DESC" -q:ON > Top100Pages.csv 
     

   • 最慢的页面

     REM "C:\Program Files (x86)\Log Parser 2.2\logparser.exe" -i:W3C -o:CSV "SELECT TOP 25 cs-uri-stem as URL-Requested, COUNT(*) AS Num-Requests, MAX(time-taken) As Max-Time-Taken, MIN(time-taken) As Min-Time-Taken, Avg(time-taken) As Average-Time-Taken FROM *.log GROUP BY URL-Requested ORDER By Average-Time-Taken DESC" -q:ON > Slowest25Pages.csv 
     

   • 超过 15 秒的所有请求

     REM "C:\Program Files (x86)\Log Parser 2.2\logparser.exe" -i:W3C -o:W3C "SELECT * FROM *.log WHERE Time-Taken > 14999 ORDER BY Time-Taken DESC" -q:ON > LongRunningRequests.log 
     

来自 Microsoft Edge 或 Chrome 的 Fiddler 跟踪或 HAR 跟踪

Fiddler Classic 有几个选项可用于查看性能信息。 在 Fiddler 中收集跟踪后，在 Fiddler 中查看 .saz 文件。 Fiddler 中有两个相关选项卡。 第一个是“统计信息 ”选项卡。在跟踪中选择多个请求（或帧），统计信息 选项卡在简单的摘要页中提供了一些性能统计信息。

用于排查性能问题的第二个 Fiddler 选项卡是 时间线 选项卡。在跟踪中选择 时间线 选项卡和多个请求（或帧），将显示一个条形图，描述客户端接收每个请求的响应所花费的时间。

F12 开发人员工具内置于 Microsoft Edge 和 Chrome 中。 在无法安装 Fiddler Classic 的情况下，这些工具可能已可供客户进行故障排除。 F12 开发人员工具类似于 Fiddler，因为它们提供所发出的请求的客户端视图。 开发人员工具 HAR 文件显示网络报表顶部的日程表，这提供了浏览器等待单个请求的时间的直观表示形式。 HAR 文件还显示一个 TIME 列，以帮助识别慢速请求。

失败的请求跟踪 （FREB） 日志

FREB 跟踪 .xml 文件，并由 FREB 日志目录中的 .xsl 样式表格式化。 使用 FrebSbS 等工具查看这些日志。 有关如何读取 FREB 日志的详细信息，请参阅 读取 FREB 日志、失败的请求跟踪：IIS 请求处理管道执行。

完整内存转储

DebugDiag 2 Analysis 应用程序可以分析转储，以查找挂起或性能问题。

若要在挂起的情况下分析单个转储，请执行以下步骤：

1. 使用“添加数据文件”按钮将转储加载到 DebugDiag 2 Analysis 中。
2. 选择 CrashHangAnalysis。
3. 选择开始分析。
4. DebugDiag 完成分析后，将在 Microsoft Edge 中打开报表。

若要分析性能问题中的一系列转储，请执行以下步骤：

1. 使用“添加数据文件”按钮添加同一进程的多个转储
2. 选择 PerfAnalysis。
3. 选择开始分析。
4. DebugDiag 完成分析后，将在 Microsoft Edge 中打开报表。

一次只运行一种类型的分析规则更为简单且更易于理解。

注释

如果需要更详细的分析，请使用 WinDbg 来查看转储。

第三方信息免责声明

本文讨论的第三方产品由独立于Microsoft的公司制造。 Microsoft对这些产品的性能或可靠性不作任何默示或其他保证。