Azure 中 Web 应用的应用程序性能常见问题解答
注意
下面的某些准则可能仅适用于 Windows 或 Linux 应用服务。 例如,Linux 应用服务默认在 64 位模式下运行。
本文对 Azure 应用服务 Web 应用功能的应用程序性能常见问题 (FAQ) 进行了解答。
如果本文未解决 Azure 问题,请访问 MSDN 和 Stack Overflow 上的 Azure 论坛。 可将问题发布到这些论坛上,或发布到 Twitter 上的 @AzureSupport。 还可提交 Azure 支持请求。 若要提交支持请求,请在 Azure 支持页上,选择“获取支持”。
为什么即使停止所有Web 应用,我的App 服务计划也会显示 CPU/内存使用率?
Azure App 服务需要持续系统进程来处理多个平台操作和功能,例如安全更新、SCM 控制台的可用性、应用程序监视、身份验证以及 Web 应用的其他许多重要功能。
即使没有Web 应用运行,或者App 服务计划不包含Web 应用,系统进程也会在App 服务计划上运行。
平台进程将消耗最少的资源(例如 CPU、内存和磁盘空间),在容量规划、监视和App 服务计划的自动缩放触发器配置期间应考虑到相同的资源。
为何我的应用运行速度缓慢?
有多种因素可能导致应用性能降低。 有关问题排查的详细步骤,请参阅 Troubleshoot slow web app performance(排查导致 Web 应用性能降低的问题)。
如何解决 CPU 占用高的问题?
在某些 CPU 占用高的情况下,应用可能真的需要更多计算资源。 在这种情况下,请考虑扩展到较高服务层级,以便应用程序可获取所需的所有资源。 其他情况下,高 CPU 占用可能是由错误循环或编码实践导致的。 深入了解 CPU 占用升高的触发因素这一过程分为两部分。 首先,创建进程转储,然后分析此进程转储。 有关详细信息,请参阅捕获和分析 Web 应用高 CPU 占用的转储文件。
如何解决内存占用高的问题?
在某些内存占用高的情况下,应用可能真的需要更多计算资源。 在这种情况下,请考虑扩展到较高服务层级,以便应用程序可获取所需的所有资源。 在其他情况下,代码中存在的 bug 可能会导致内存泄漏。 此外,编码实践也可能会增大内存占用。 深入了解内存占用高的触发因素这一过程分为两部分。 首先,创建进程转储,然后分析此进程转储。 Azure 站点扩展库中的故障诊断程序可高效执行这两个步骤。 有关详细信息,请参阅捕获和分析 Web 应用间歇性高内存的转储文件。
如何使用 PowerShell 实现应用服务 Web 应用的自动化?
可以使用 PowerShell cmdlet 管理和维护应用服务 Web 应用。 在我们的博客文章 Automate web apps hosted in Azure App Service by using PowerShell(使用 PowerShell 实现 Azure 应用服务中托管的 Web 应用的自动化)中,我们将说明如何使用基于 Azure Resource Manager 的 PowerShell cmdlet 自动执行常见任务。 此博客文章中还包含适用于各种 Web 应用管理任务的示例代码。 有关所有应用服务 Web 应用 cmdlet 的说明和语法,请参阅 Az.Websites。
如何查看 Web 应用的事件日志?
查看 Web 应用的事件日志:
- 登录到 Kudu 网站 (
https://*yourwebsitename*.scm.azurewebsites.net
)。 - 在菜单中,选择“调试控制台”>“CMD”。
- 选择“LogFiles”文件夹。
- 若要查看事件日志,请选择 eventlog.xml 旁的铅笔图标。
- 若要下载日志,请运行 PowerShell cmdlet
Save-AzureWebSiteLog -Name webappname
。
如何捕获 Web 应用的用户模式内存转储?
若要捕获 Web 应用的用户模式内存转储,请执行以下操作:
- 登录到 Kudu 网站 (
https://*yourwebsitename*.scm.azurewebsites.net
)。 - 选择“进程资源管理器”菜单。
- 右键单击“w3wp.exe”进程或 WebJob 进程。
- 选择“下载内存转储”>“完全转储”。
如何查看 Web 应用的进程级信息?
可通过两种方法查看 Web 应用的进程级信息:
- 在 Azure 门户中:
- 打开 Web 应用的“进程资源管理器”。
- 若要查看详细信息,请选择“w3wp.exe”进程。
- 在 Kudu 控制台中:
- 登录到 Kudu 网站 (
https://*yourwebsitename*.scm.azurewebsites.net
)。 - 选择“进程资源管理器”菜单。
- 对于“w3wp.exe”进程,选择“属性”。
- 登录到 Kudu 网站 (
当我浏览到我的应用时,我看到“错误 403 - 此 Web 应用已停止”。如何实现解决此问题?
有三种情况可能导致此错误:
- Web 应用已达到计费限制,站点已被禁用。
- 已在门户中停止 Web 应用。
- Web 应用已达到资源配额限制,该限制可能适用于免费或共享缩放服务计划。
若要了解导致错误的原因并解决问题,请按照 Web 应用:“错误 403 – 此 Web 应用已停止”中的步骤执行。
可从何处了解有关各种应用服务计划的配额和限制的详细信息?
有关配额和限制的信息,请参阅应用服务限制。
如何缩短空闲时间后第一个请求的响应时间?
默认情况下,如果 Web 应用在一段时间内处于空闲状态,则会卸载这些应用。 这样,系统可以节省资源。 其缺点是:Web 应用处于未加载的状态后,对第一个请求的响应时间较长,需要等待 Web 应用加载和启动处理响应。 在基本和标准服务计划中,可启用“始终打开”设置,使应用保持加载状态。 这样就无需在应用处于空闲状态后重新加载应用。 若要更改“始终打开”设置,请执行以下操作:
- 在 Azure 门户中,转到自己的 Web 应用。
- 选择“配置”
- 选择“常规设置”。
- 对于“始终打开”,选择“打开”。
如何打开失败请求跟踪?
若要启用失败的请求跟踪,请执行以下步骤:
在 Azure 门户中,转到自己的 Web 应用。
选择“所有设置”>“诊断日志”。
对于“失败请求跟踪”,选择“打开”。
选择“保存”。
在 Web 应用边栏选项卡,选择“工具”。
选择“Visual Studio Online”。
如果设置未打开,请选择“开”。
选择“转到”。
选择 Web.config。
在 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>
若要对性能缓慢问题进行故障排除,请添加此配置(如果捕获请求时间超过 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>
若要下载失败请求跟踪,请在门户中,转到你的网站。
选择“工具”>“Kudu”>“转到”。
在菜单中,选择“调试控制台”>“CMD”。
选择 LogFiles 文件夹,然后选择名称以 W3SVC 开头的文件夹。
若要查看 XML 文件,请选择铅笔图标。
我看到消息“由于”百分比内存“限制而请求回收的辅助进程。如何实现解决此问题?
对于 32 位的进程(即使是在 64 位操作系统中),最大可用内存量是 2 GB。 默认情况下,应用服务中的工作进程设置为 32 位(以便与旧版 Web 应用程序兼容)。
请考虑切换为 64 位进程,以便利用 Web 辅助角色中的其他可用内存。 此操作触发 Web 应用重启,因此请相应地进行计划。
另请注意,64 位环境需要“基本”或“标准”服务计划。 “免费”和“共享”计划始终在 32 位环境中运行。
有关详细信息,请参阅在应用服务中配置 web 应用。
为何我的请求在 230 秒后超时?
Azure 负载均衡器的默认空闲超时设置为四分钟。 此设置通常是 Web 请求的合理响应时间限制。 因此,如果应用程序在大约 240 秒(Windows 应用 230 秒,Linux 应用 240 秒)内未返回响应,则App 服务向客户端返回超时。 如果你的 Web 应用需要后台处理,则建议使用 Azure Web 作业。 Azure Web 应用可以调用 Web 作业,并在后台处理完成时收到通知。 可以在多种 Web 作业使用方法(包括队列和触发器)中进行选择。
Web 作业旨在用于后台处理。 可以在 Web 作业中根据需要执行后台处理。 有关 Web 作业的详细信息,请参阅使用 Web 作业运行后台任务。
应用服务中托管的 ASP.NET Core 应用程序有时会停止响应。 如何解决此问题?
早期 Kestrel 版本的已知问题可能会导致托管于应用服务中的 ASP.NET Core 1.0 应用间歇性地停止响应。 还可能会看到以下消息:“指定的 CGI 应用程序遇到错误,服务器终止了该进程”。
已在 Kestrel 版本 1.0.2 中修复了此问题。 此版本包含在 ASP.NET Core 1.0.3 更新中。 若要解决此问题,请确保将你的应用依赖项更新为使用 Kestrel 1.0.2。 或者,可以使用博客文章 ASP.NET Core 1.0 slow perf issues in App Service web apps(应用服务 Web 应用中 ASP.NET Core 1.0 低性能问题)中介绍的两种解决方法之一。
在 Web 应用的文件结构中找不到日志文件。 如何找到它们?
如果使用应用服务的本地缓存功能,应用服务实例“LogFiles 和数据”文件夹的文件夹结构会受到影响。 使用本地缓存时,将在存储 LogFiles 和数据文件夹中创建子文件夹。 子文件夹使用“唯一标识符”+ 时间戳的命名模式。 每个子文件夹对应于一个 VM 实例,其中的 Web 应用正在运行或已运行。
若要确定是否使用本地缓存,请检查App 服务应用程序设置选项卡。如果使用本地缓存,则应用设置WEBSITE_LOCAL_CACHE_OPTION
设置为 Always
。
如果未使用本地缓存并且遇到此问题,请提交支持请求。
我看到消息“尝试以禁止其访问权限的方式访问套接字”。如何实现解决此错误?
将发生此错误通常是因为 VM 实例上的出站 TCP 连接耗尽。 在应用服务中,将强制限制每个 VM 实例的最大出站连接数。 有关详细信息,请参阅跨 VM 数字限制。
如果尝试从应用程序访问本地地址,也可能发生此错误。 有关详细信息,请参阅本地地址请求。
有关 Web 应用中的出站连接的详细信息,请参阅有关到 Azure 网站的传出连接的博客文章。
如何使用 Visual Studio 远程调试应用服务 Web 应用?
有关如何使用 Visual Studio 调试 Web 应用的详细演练,请参阅 Remote debug your App Service web app(远程调试应用服务 Web 应用)。
联系我们寻求帮助
如果你有任何疑问或需要帮助,请创建支持请求或联系 Azure 社区支持。 你还可以将产品反馈提交到 Azure 反馈社区。