Application performance FAQs for Web Apps in Azure

Multiple factors might contribute to slow app performance. For detailed troubleshooting steps, see Troubleshoot slow web app performance.

In some high CPU-consumption scenarios, your app might truly require more computing resources. In that case, consider scaling to a higher service tier so the application gets all the resources it needs. Other times, high CPU consumption might be caused by a bad loop or by a coding practice. Getting insight into what's triggering increased CPU consumption is a two-part process. First, create a process dump, and then analyze the process dump. For more information, see Capture and analyze a dump file for high CPU consumption for Web Apps.

In some high memory-consumption scenarios, your app might truly require more computing resources. In that case, consider scaling to a higher service tier so the application gets all the resources it needs. Other times, a bug in the code might cause a memory leak. A coding practice also might increase memory consumption. Getting insight into what's triggering high memory consumption is a two-part process. First, create a process dump, and then analyze the process dump. Crash Diagnoser from the Azure Site Extension Gallery can efficiently perform both these steps. For more information, see Capture and analyze a dump file for intermittent high memory for Web Apps.

You can use PowerShell cmdlets to manage and maintain App Service web apps. In our blog post Automate web apps hosted in Azure App Service by using PowerShell, we describe how to use Azure Resource Manager-based PowerShell cmdlets to automate common tasks. The blog post also has sample code for various web apps management tasks. For descriptions and syntax for all App Service web apps cmdlets, see Az.Websites.

To view your web app's event logs:

1. Sign in to your Kudu website (https://*yourwebsitename*.scm.chinacloudsites.cn).
2. In the menu, select Debug Console > CMD.
3. Select the LogFiles folder.
4. To view event logs, select the pencil icon next to eventlog.xml.
5. To download the logs, run the PowerShell cmdlet Save-AzureWebSiteLog -Name webappname.

To capture a user-mode memory dump of your web app:

1. Sign in to your Kudu website (https://*yourwebsitename*.scm.chinacloudsites.cn).
2. Select the Process Explorer menu.
3. Right-click the w3wp.exe process or your WebJob process.
4. Select Download Memory Dump > Full Dump.

You have two options for viewing process-level information for your web app:

• In the Azure portal:
  1. Open the Process Explorer for the web app.
  2. To see the details, select the w3wp.exe process.
• In the Kudu console:
  1. Sign in to your Kudu website (https://*yourwebsitename*.scm.chinacloudsites.cn).
  2. Select the Process Explorer menu.
  3. For the w3wp.exe process, select Properties.

Three conditions can cause this error:

• The web app has reached a billing limit and your site has been disabled.
• The web app has been stopped in the portal.
• The web app has reached a resource quota limit that might apply to a Free or Shared scale service plan.

To see what is causing the error and to resolve the issue, follow the steps in Web Apps: "Error 403 - This web app is stopped".

For information about quotas and limits, see App Service limits.

By default, web apps are unloaded if they are idle for a set period of time. This way, the system can conserve resources. The downside is that the response to the first request after the web app is unloaded is longer, to allow the web app to load and start serving responses. In Basic and Standard service plans, you can turn on the Always On setting to keep the app always loaded. This eliminates longer load times after the app is idle. To change the Always On setting:

1. In the Azure portal, go to your web app.
2. Select Configuration
3. Select General settings.
4. For Always On, select On.

The maximum available amount of memory for a 32-bit process (even on a 64-bit operating system) is 2 GB. By default, the worker process is set to 32-bit in App Service (for compatibility with legacy web applications).

Consider switching to 64-bit processes so you can take advantage of the additional memory available in your Web Worker role. This triggers a web app restart, so schedule accordingly.

Also note that a 64-bit environment requires a Basic or Standard service plan. Free and Shared plans always run in a 32-bit environment.

For more information, see Configure web apps in App Service.

A known issue with an earlier Kestrel version might cause an ASP.NET Core 1.0 app that's hosted in App Service to intermittently stop responding. You also might see this message: "The specified CGI Application encountered an error and the server terminated the process."

This issue is fixed in Kestrel version 1.0.2. This version is included in the ASP.NET Core 1.0.3 update. To resolve this issue, make sure you update your app dependencies to use Kestrel 1.0.2. Alternatively, you can use one of two workarounds that are described in the blog post ASP.NET Core 1.0 slow perf issues in App Service web apps.

If you use the Local Cache feature of App Service, the folder structure of the LogFiles and Data folders for your App Service instance are affected. When Local Cache is used, subfolders are created in the storage LogFiles and Data folders. The subfolders use the naming pattern "unique identifier" + time stamp. Each subfolder corresponds to a VM instance in which the web app is running or has run.

To determine whether you are using Local Cache, check your App Service Application settings tab. If Local Cache is being used, the app setting WEBSITE_LOCAL_CACHE_OPTION is set to Always.

If you are not using Local Cache and are experiencing this issue, submit a support request.

This error typically occurs if the outbound TCP connections on the VM instance are exhausted. In App Service, limits are enforced for the maximum number of outbound connections that can be made for each VM instance. For more information, see Cross-VM numerical limits.

This error also might occur if you try to access a local address from your application. For more information, see Local address requests.

For more information about outbound connections in your web app, see the blog post about outgoing connections to Azure websites.

For a detailed walkthrough that shows you how to debug your web app by using Visual Studio, see Remote debug your App Service web app.