通过

你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

排查 Azure Front Door 的常规性能问题

  • 项目

性能问题可能源于多个潜在方面：Azure Front Door 服务、源、请求客户端或这些跃点之间的路径。 此故障排除指南可帮助你确定数据路径上的哪个跃点最有可能是问题的根源以及如何解决该问题。

检查是否存在已知问题

在开始之前，请检查以下方面是否存在任何已知问题：

  • Azure Front Door 平台。
  • 路径中的 Internet 服务提供商 (ISP)。
  • 请求客户端的连接和检索数据的功能。

场景 1：调查源

如果源服务器之一速度较慢，则通过 Azure Front Door 针对某个对象发出的第一个请求会较慢。 此外，如果内容未缓存在 Azure Front Door 接入点 (POP)，则请求将转发到源。 从源提供消除了 POP 相对于请求客户端的邻近和本地传送优势，因而改为依赖源的性能。

场景 1：所需的环境信息

  • Azure Front Door 终结点名称
    • 终结点主机名
    • 终结点自定义域（如适用）
    • 源主机名
  • 受影响文件的完整 URL

场景 1：故障排除步骤

  1. 检查受影响请求的响应头。

    若要检查响应头，请在 Bash 中使用以下 curl 示例。 还可以通过选择 F12 键来使用浏览器的开发人员工具。 选择“网络”选项卡，选择要调查的相关文件，然后选择“标头”选项卡。如果该文件缺失，请在打开开发人员工具的情况下重新加载页面。

    初始响应应该有一个带 TCP_MISS 或 CONFIG_NOCACHE 值的 x-cache 标头。 Azure Front Door POP 会将包含此值的请求转发到源。 源将该路径上的返回流量发送到请求客户端。

    下面是一个显示 TCP_MISS 的示例：

    $ curl -I https://www.contoso.com/styles.css
HTTP/2 200
date: Wed, 28 Aug 2024 17:02:09 GMT
content-type: text/css
content-length: 2837
last-modified: Thu, 09 May 2024 20:49:36 GMT
etag: "b15-6180b8e9bd897"
vary: Accept-Encoding
x-azure-ref: 20240828T170209Z-AA11BB22CC33DD44EE55FF66AA77BB88CC99DD00
x-fd-int-roxy-purgeid: 0
x-cache: TCP_MISS
accept-ranges: bytes

    下面是一个显示 TCP_HIT 的示例：

    curl -I https://www.contoso.com/styles.css
HTTP/2 200
date: Wed, 28 Aug 2024 17:04:38 GMT
content-type: text/css
content-length: 2837
last-modified: Thu, 09 May 2024 20:49:36 GMT
etag: "b15-6180b8e9bd897"
vary: Accept-Encoding
x-azure-ref: 20240828T170438Z-BB22CC33DD44EE55FF66AA77BB88CC99DD00EE11
x-fd-int-roxy-purgeid: 0
x-cache: TCP_HIT
x-cache-info: L1_T2
accept-ranges: bytes

  2. 继续对终结点发出请求，直到 x-cache 标头具有 TCP_HIT 值。

    如果最初看到 CONFIG_NOCACHE，则路由配置中未启用高速缓存。 在这种情况下，你不会看到 TCP_HIT。

  3. 如果性能问题得到解决，则表明问题是基于源的速度而不是 Azure Front Door 的性能。 所有者需要解决 Azure Front Door 缓存设置或源的问题才能提高性能。

    如果问题仍然存在，源可能是正在请求内容或 Azure Front Door 服务的客户端。 转到场景 2 以识别源。

场景 2：单个客户端或位置（例如某个 ISP）速度缓慢

如果请求客户端与 Azure Front Door POP 之间存在错误的网络路由，则单个客户端或位置的速度可能会很慢。 应排除任何错误路由，因为它会影响到 POP 的距离，从而消除 Azure Front Door POP 的邻近优势。

如果使用虚拟专用网络 (VPN) 或分布式企业网络，则高延迟或低带宽可能是 ISP 问题造成的。 企业网络可以通过中心远程点运行所有流量。

场景 2：所需的环境信息

  • Azure Front Door 终结点名称
    • 终结点主机名
    • 终结点自定义域（如适用）
    • 源主机名
  • 受影响文件的完整 URL
  • 请求客户端信息
    • 请求客户端 IP
    • 请求客户端位置
    • Azure 环境的请求客户端路径（通常使用 tracert、pathping 或类似工具进行标识）

场景 2：故障排除步骤

  1. 若要检查 POP 的路径，请使用 pathping 或类似工具处理 500 个数据包来检查网络路由。

    pathping 最多可以有 250 个查询。 若要针对 500 个查询进行测试，请运行以下查询两次：

    pathping /q 250 <Full URL of Affected File>

  2. 确定流量是否采用将增加时间或前往遥远区域的路径。

    根据你的地理位置查找未采用合理路由（例如，欧洲的流量路由到美国）或跃点过多的 IP、城市或区域代码。

  3. 若要排除请求客户端的设置，请用同一区域中的不同请求客户端进行测试。

  4. 如果识别了其他跃点或远程区域，则问题出在客户端访问 Azure Front Door POP，而不是出在 Azure Front Door 服务本身。 连接服务提供商或 VPN 提供商需要解决终结点之间的跃点的问题。

    如果没有识别其他跃点或远程区域，而内容是从缓存 (x-cache: TCP_HIT) 提供的，则问题出在 Azure Front Door 服务。 可能需要创建支持请求。 包括对此故障排除文章和所执行步骤的引用。

注意

从源 (x-cache: TCP_MISS) 提供内容时，请参阅本文前面的场景 1。

场景 3：网站加载缓慢

某些情况下，单个文件没有问题，但整个（Azure Front Door 代理）网页的性能却不能令人满意。 网页性能工具显示的站点性能较差（与 Azure Front Door 之外的网页相比）。

网页通常由多个文件组成。 只有在 Azure Front Door 提供网页上的每个文件的情况下，网站才会受益于 Azure Front Door。 必须通过配置 Azure Front Door 最大程度地提高好处。

请考虑以下示例：

  • 源：origin.contoso.com
  • Azure Front Door 自定义域：contoso.com
  • 尝试加载的页面：https://contoso.com

加载页面时，位于“/”目录的初始文件会调用用于生成页面的其他文件。 这些文件是图像、JavaScript、文本文件等。 如果这些文件不是通过 Azure Front Door 主机名 (contoso.com) 调用的，则表明该页面不使用 Azure Front Door。 因此，如果网站请求的文件之一是 http://www.images.fabrikam.com/businessimage.jpg，则该文件不受益于 Azure Front Door 的使用。 系统会改为让请求客户端上的浏览器直接从 images.fabrikam.com 服务器请求文件。

此图显示单个网站的多个来源不同的文件，以及该配置影响 Azure Front Door 性能的情况。

场景 3：所需的环境信息

  • Azure Front Door 终结点名称
    • 终结点主机名
    • 终结点自定义域（如适用）
    • 源主机名
    • 源的地理位置
  • 受影响网页的完整 URL
  • 衡量性能的工具和指标

场景 3：故障排除

  1. 查看显示性能较慢的指标。

    重要

    Microsoft 无法辨别其不拥有的工具正在测量的内容。

  2. 在浏览器中打开 Azure Front Door 网页，然后选择 F12 键以打开开发人员工具。

    可以使用浏览器中的开发人员工具来确定所提供文件的源。 若要在开发人员工具中查看请求 URL，请依次选择“网络”选项卡、要调查的文件、“常规”。 如果该文件缺失，请在打开开发人员工具的情况下重新加载页面。

  3. 请记下文件的源或请求 URL。

  4. 确定哪些文件在使用 Azure Front Door 主机名，哪些文件没有在使用。

    在上一示例中，Azure Front Door 中托管的映像将为 https://www.contoso.com/productimage1.jpg。 未托管在 Azure Front Door 中的映像将为 http://www.images.fabrikam.com/businessimage.jpg。

  5. 测试 Azure Front Door 所提供的文件的性能、其源以及（适用情况下的）测试网页。

    如果源或测试网页是从更接近性能测试工具的地理区域提供的，则可能需要在另一个区域中使用工具或请求客户端来检查 Azure Front Door POP 的邻近优势。

    重要

    从 Azure Front Door 主机名外部提供的任何文件都不会从中受益。 为此，你可能需要重新设计网页。

    如果要缓存文件，请务必测试响应头为 x-cache: TCP_HIT 的文件。

  6. 根据收集的数据执行操作：

    • 如果收集的数据显示文件是从 Azure Front Door 主机名之外的服务器发出的，则表明 Azure Front Door 在正常工作。

      如果网站加载缓慢，则可能需要更改网页设计。 如果需要他人帮助来优化网站以使用 Azure Front Door，请与网站设计团队或 Microsoft 解决方案提供商联系。

      注意

      网站加载速度缓慢的问题可能需要一定的时间进行审查，具体取决于网站设计的复杂性以及文件调用说明。

    • 如果收集的数据显示文件在 Azure Front Door 上的加载性能优于源或测试站点，则表明 Azure Front Door 在正常工作。 问题的根源可能是单个客户端请求。 这种情况下，请参阅本文前面的场景 1。

    • 如果收集的数据表明 Azure Front Door 上的性能并没有更好，你可能需要提交支持请求，以便我们进一步进行调查。 包括对此故障排除文章和所执行步骤的引用。