Azure 中Web 应用的应用程序性能常见问题解答

备注

以下某些准则可能仅适用于 Windows 或 Linux 应用服务。 例如,默认情况下,Linux 应用服务以 64 位模式运行。

本文解答了常见问题解答 (常见问题解答) 有关Azure 应用服务Web 应用功能的应用程序性能问题。

如果本文未解决 Azure 问题,请访问 MSDN和 Stack Overflow 上的 Azure 论坛。 可以在这些论坛中发布问题,或在 @AzureSupport Twitter 上发布问题。 还可以提交 Azure 支持请求。 若要提交支持请求,请在 Azure 支持 页面上 ,选择获取 支持

为什么我的应用速度缓慢?

多种因素可能会导致应用性能降低。 有关详细的故障排除步骤,请参阅 排查 Web 应用性能缓慢的问题

如何实现排查高 CPU 消耗情况的问题?

在某些 CPU 消耗较高的方案中,应用可能确实需要更多计算资源。 在这种情况下,请考虑缩放到更高的服务层级,以便应用程序获取所需的所有资源。 其他时候,CPU 消耗量过高可能是由于循环错误或编码做法造成的。 深入了解是什么触发了 CPU 消耗的增加,这是一个由两部分组成的过程。 首先,创建进程转储,然后分析进程转储。 有关详细信息,请参阅捕获和分析转储文件,以实现高 CPU 消耗Web 应用

如何实现排查高内存消耗情况的问题?

在某些内存消耗较高的方案中,应用可能确实需要更多计算资源。 在这种情况下,请考虑缩放到更高的服务层级,以便应用程序获取所需的所有资源。 其他时候,代码中的 bug 可能会导致内存泄漏。 编码做法也可能会增加内存消耗。 深入了解触发高内存消耗的因素是一个两部分的过程。 首先,创建进程转储,然后分析进程转储。 Azure 站点扩展库中的故障诊断器可以有效地执行这两个步骤。 有关详细信息,请参阅捕获和分析转储文件,了解Web 应用的间歇性高内存

如何实现使用 PowerShell 自动App 服务 Web 应用?

可以使用 PowerShell cmdlet 管理和维护App 服务 Web 应用。 在博客文章中,我们介绍了如何使用基于 Azure 资源管理器 的 PowerShell cmdlet 自动执行常见任务,从而自动执行托管在 Azure 应用服务 中的 Web 应用。 博客文章还包含各种 Web 应用管理任务的示例代码。 有关所有App 服务 Web 应用 cmdlet 的说明和语法,请参阅 Az.Websites

如何实现查看 Web 应用的事件日志?

若要查看 Web 应用的事件日志,请执行以下操作:

  1. 登录 到 Kudu 网站 () https://*yourwebsitename*.scm.azurewebsites.net
  2. 在菜单中,选择 “调试控制台 > CMD”。
  3. 选择 LogFiles 文件夹。
  4. 若要查看事件日志,请选择 eventlog.xml 旁边的铅笔图标。
  5. 若要下载日志,请运行 PowerShell cmdlet Save-AzureWebSiteLog -Name webappname

如何实现捕获 Web 应用的用户模式内存转储?

若要捕获 Web 应用的用户模式内存转储,请执行以下操作:

  1. 登录 到 Kudu 网站 () https://*yourwebsitename*.scm.azurewebsites.net
  2. 选择 “进程资源管理器” 菜单。
  3. 右键单击 w3wp.exe 进程或 WebJob 进程。
  4. 选择 “下载内存转储 > ”完整转储

如何实现查看 Web 应用的进程级别信息?

有两个选项可用于查看 Web 应用的进程级信息:

  • 在 Azure 门户中:
    1. 打开 Web 应用的 进程资源管理器
    2. 若要查看详细信息,请选择 w3wp.exe 过程。
  • 在 Kudu 控制台中:
    1. 登录 到 Kudu 网站 () https://*yourwebsitename*.scm.azurewebsites.net
    2. 选择 “进程资源管理器” 菜单。
    3. 对于 w3wp.exe 过程,请选择 “属性”。

浏览到应用时,会看到“错误 403 - 此 Web 应用已停止”。 如何实现解决此问题?

三个条件可能导致此错误:

  • Web 应用已达到计费限制,网站已禁用。
  • Web 应用已在门户中停止。
  • Web 应用已达到可能适用于免费或共享缩放服务计划的资源配额限制。

若要查看导致错误的原因并解决问题,请按照Web 应用中的步骤操作:“错误 403 – 此 Web 应用已停止”。

在哪里可以详细了解各种App 服务计划的配额和限制?

有关配额和限制的信息,请参阅App 服务限制

如何实现在空闲时间后减少第一个请求的响应时间?

默认情况下,如果 Web 应用在一定时间段内处于空闲状态,则会卸载它们。 这样,系统就可以节省资源。 缺点是,卸载 Web 应用后对第一个请求的响应更长,以允许 Web 应用加载并开始为响应提供服务。 在基本和标准服务计划中,可以启用 Always On 设置,使应用始终加载。 这样可以消除应用处于空闲状态后更长的加载时间。 若要更改 Always On 设置:

  1. 在Azure 门户中,转到 Web 应用。
  2. 选择 配置
  3. 选择 “常规设置”。
  4. 对于 Always On,请选择 “打开”。

如何实现启用失败的请求跟踪?

若要启用失败的请求跟踪,请执行以下步骤:

  1. 在Azure 门户中,转到 Web 应用。

  2. 选择 “所有设置 > 诊断日志”。

  3. 对于 失败的请求跟踪,请选择 “打开”。

  4. 选择“保存”。

  5. 在 Web 应用边栏选项卡上,选择 “工具”。

  6. 选择 Visual Studio Online

  7. 如果设置未 打开,请选择 “打开”。

  8. 选择 转到

  9. 选择 Web.config

  10. 在 system.webServer 中,添加以下配置 (以捕获特定的 URL) :

    <system.webServer>
    <tracing> <traceFailedRequests>
    <remove path="*api*" />
    <add path="*api*">
    <traceAreas>
    <add provider="ASP" verbosity="Verbose" />
    <add provider="ASPNET" areas="Infrastructure,Module,Page,AppServices" verbosity="Verbose" />
    <add provider="ISAPI Extension" verbosity="Verbose" />
    <add provider="WWW Server" areas="Authentication,Security,Filter,StaticFile,CGI,Compression, Cache,RequestNotifications,Module,FastCGI" verbosity="Verbose" />
    </traceAreas>
    <failureDefinitions statusCodes="200-999" />
    </add> </traceFailedRequests>
    </tracing>
    
  11. 若要排查性能缓慢的问题,请在捕获请求需要超过 30 秒) 时添加此配置 (:

    <system.webServer>
    <tracing> <traceFailedRequests>
    <remove path="*" />
    <add path="*">
    <traceAreas> <add provider="ASP" verbosity="Verbose" />
    <add provider="ASPNET" areas="Infrastructure,Module,Page,AppServices" verbosity="Verbose" />
    <add provider="ISAPI Extension" verbosity="Verbose" />
    <add provider="WWW Server" areas="Authentication,Security,Filter,StaticFile,CGI,Compression, Cache,RequestNotifications,Module,FastCGI" verbosity="Verbose" />
    </traceAreas>
    <failureDefinitions timeTaken="00:00:30" statusCodes="200-999" />
    </add> </traceFailedRequests>
    </tracing>
    
  12. 若要下载失败的请求跟踪,请在 门户中转到您的网站。

  13. 选择 “工具 > Kudu > Go”。

  14. 在菜单中,选择 “调试控制台 > CMD”。

  15. 选择 LogFiles 文件夹,然后选择名称以 W3SVC 开头的文件夹。

  16. 若要查看 XML 文件,请选择铅笔图标。

我看到消息“辅助进程由于'内存百分比'限制而请求回收。 如何实现解决此问题?

32 位进程的最大可用内存量 (即使在 64 位操作系统上) 也是 2 GB。 默认情况下,工作进程设置为 32 位App 服务 (,以便与旧版 Web 应用程序) 兼容。

请考虑切换到 64 位进程,以便可以利用 Web 辅助角色中可用的其他内存。 此操作会触发 Web 应用重启,因此请相应地计划。

另请注意,64 位环境需要基本或标准服务计划。 免费和共享计划始终在 32 位环境中运行。

有关详细信息,请参阅App 服务中配置 Web 应用

为什么我的请求在 230 秒后超时?

Azure 负载均衡器的默认空闲超时设置为 4 分钟。 此设置通常是 Web 请求的合理响应时间限制。 因此,如果应用程序在 Windows 应用上大约 240 秒 (230 秒内(在 Linux 应用) 上 240 秒)内未返回响应,App 服务会向客户端返回超时。如果 Web 应用需要后台处理,建议使用 Azure WebJobs。 Azure Web 应用可以调用 WebJobs,并在完成后台处理时收到通知。 可以从多个使用 WebJobs 的方法(包括队列和触发器)中进行选择。

WebJobs 专为后台处理而设计。 可以在 WebJob 中根据需要执行尽可能多的后台处理。 有关 WebJobs 的详细信息,请参阅 使用 WebJobs 运行后台任务

ASP.NET Core托管在App 服务中的应用程序有时会停止响应。 如何实现解决此问题?

早期 Kestrel 版本的已知问题可能导致托管在 App 服务 中的 ASP.NET Core 1.0 应用断断续续地停止响应。 还可能会看到以下消息:“指定的 CGI 应用程序遇到错误,服务器终止了进程。

此问题已在 Kestrel 版本 1.0.2 中修复。 此版本包含在 ASP.NET Core 1.0.3 更新中。 若要解决此问题,请确保更新应用依赖项以使用 Kestrel 1.0.2。 或者,可以使用博客文章中描述的两种解决方法之一 ASP.NET Core App 服务 Web 应用中的 1.0 慢速填充问题

在 Web 应用的文件结构中找不到日志文件。 如何找到它们?

如果使用App 服务的本地缓存功能,则App 服务实例的 LogFiles 和 Data 文件夹的文件夹结构将受到影响。 使用本地缓存时,会在存储 LogFiles 和数据文件夹中创建子文件夹。 子文件夹使用命名模式“唯一标识符”+ 时间戳。 每个子文件夹对应于运行或运行 Web 应用的 VM 实例。

若要确定是否使用本地缓存,请检查App 服务 “应用程序设置” 选项卡。如果正在使用本地缓存,应用设置WEBSITE_LOCAL_CACHE_OPTION将设置为Always

如果未使用本地缓存且遇到此问题,请提交支持请求。

我看到消息“试图以其访问权限禁止的方式访问套接字。 如何实现解决此错误?

如果 VM 实例上的出站 TCP 连接已用尽,则通常会发生此错误。 在App 服务中,对可为每个 VM 实例建立的最大出站连接数强制实施限制。 有关详细信息,请参阅 跨 VM 数值限制

如果尝试从应用程序访问本地地址,也可能出现此错误。 有关详细信息,请参阅 本地地址请求

有关 Web 应用中的出站连接的详细信息,请参阅有关 到 Azure 网站的传出连接的博客文章。

如何实现使用 Visual Studio 远程调试我的App 服务 Web 应用?

有关演示如何使用 Visual Studio 调试 Web 应用的详细演练,请参阅远程调试App 服务 Web 应用

联系我们寻求帮助

如果你有任何疑问或需要帮助,请创建支持请求联系 Azure 社区支持