Azure での Web アプリのアプリケーションパフォーマンスに関するよくあるご質問Application performance FAQs for Web Apps in Azure

注意

以下のガイドラインのいくつかは、Windows または Linux App Services でのみ有効な場合があります。Some of the below guidelines might only work on Windows or Linux App Services. たとえば、Linux App Services は既定で 64 ビット モードで動作します。For example, Linux App Services run in 64-bit mode by default.

この記事では、Azure App Service の Web アプリ機能でのアプリケーション パフォーマンスの問題に関するよくあるご質問 (FAQ) への回答を示します。This article has answers to frequently asked questions (FAQs) about application performance issues for the Web Apps feature of Azure App Service.

この記事で Azure の問題に対処できない場合は、MSDN および Stack Overflow の Azure 関連フォーラムを参照してください。If your Azure issue is not addressed in this article, visit the Azure forums on MSDN and Stack Overflow. 問題をこれらのフォーラムまたは Twitter の @AzureSupport に投稿できます。You can post your issue in these forums, or post to @AzureSupport on Twitter. Azure サポート要求を送信することもできます。You also can submit an Azure support request. サポート要求を送信するには、[Azure サポート] ページで [サポートを受ける] を選択します。To submit a support request, on the Azure support page, select Get support.

アプリが低速なのはなぜですか?Why is my app slow?

アプリの低速なパフォーマンスには複数の要因が関与している可能性があります。Multiple factors might contribute to slow app performance. 詳細なトラブルシューティング手順については、「Troubleshoot slow web app performance (Web アプリの低速なパフォーマンスのトラブルシューティング)」を参照してください。For detailed troubleshooting steps, see Troubleshoot slow web app performance.

CPU 使用量が多いシナリオをトラブルシューティングするにはどうすればよいですか?How do I troubleshoot a high CPU-consumption scenario?

CPU 使用量が多い一部のシナリオでは、アプリが実際により多くのコンピューティング リソースを必要としている可能性があります。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. その他の場合、CPU 使用量の多さは、不適切なループまたはコーディング方法によって発生している可能性があります。Other times, high CPU consumption might be caused by a bad loop or by a coding practice. CPU 使用量が増えている原因の調査は 2 つの部分からなるプロセスです。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. 詳細については、「Capture and analyze a dump file for high CPU consumption for Web Apps (Web アプリの増加した CPU 使用量のためのダンプ ファイルの取得と分析)」を参照してください。For more information, see Capture and analyze a dump file for high CPU consumption for Web Apps.

メモリ使用量が多いシナリオをトラブルシューティングするにはどうすればよいですか?How do I troubleshoot a high memory-consumption scenario?

メモリ使用量が多い一部のシナリオでは、アプリが実際により多くのコンピューティング リソースを必要としている可能性があります。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. メモリ使用量が多い原因の調査は 2 つの部分からなるプロセスです。 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. Azure サイト拡張機能ギャラリーのクラッシュ診断は、これらの手順の両方を効率的に実行できます。Crash Diagnoser from the Azure Site Extension Gallery can efficiently perform both these steps. 詳細については、「Capture and analyze a dump file for intermittent high memory for Web Apps (Web アプリの断続的な増加したメモリ使用量のためのダンプ ファイルの取得と分析)」を参照してください。For more information, see Capture and analyze a dump file for intermittent high memory for Web Apps.

PowerShell を使用して App Service Web アプリを自動化するにはどうすればよいですか?How do I automate App Service web apps by using PowerShell?

PowerShell コマンドレットを使用すると、App Service Web アプリを管理および維持できます。You can use PowerShell cmdlets to manage and maintain App Service web apps. ブログの投稿「Automate web apps hosted in Azure App Service by using PowerShell (PowerShell を使用して Azure App Service でホストされた Web アプリを自動化する)」では、Azure Resource Manager ベースの PowerShell コマンドレットを使用して一般的なタスクを自動化する方法について説明しています。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. このブログの投稿にはまた、さまざまな Web アプリ管理タスクのサンプル コードも含まれています。The blog post also has sample code for various web apps management tasks. すべての App Service Web アプリ コマンドレットの説明と構文については、「Az.Websites」を参照してください。For descriptions and syntax for all App Service web apps cmdlets, see Az.Websites.

Web アプリのイベント ログを表示するにはどうすればよいですか?How do I view my web app's event logs?

Web アプリのイベント ログを表示するには:To view your web app's event logs:

  1. Kudu の Web サイトにサインインします。Sign in to your Kudu website.
  2. メニューで、 [デバッグ コンソール] > [CMD] を選択します。In the menu, select Debug Console > CMD.
  3. LogFiles フォルダーを選択します。Select the LogFiles folder.
  4. イベント ログを表示するには、eventlog.xml の横にある鉛筆アイコンを選択します。To view event logs, select the pencil icon next to eventlog.xml.
  5. ログをダウンロードするには、PowerShell コマンドレット Save-AzureWebSiteLog -Name webappname を実行します。To download the logs, run the PowerShell cmdlet Save-AzureWebSiteLog -Name webappname.

Web アプリのユーザーモードのメモリ ダンプをキャプチャするにはどうすればよいですか?How do I capture a user-mode memory dump of my web app?

Web アプリのユーザーモードのメモリ ダンプをキャプチャするには:To capture a user-mode memory dump of your web app:

  1. Kudu の Web サイトにサインインします。Sign in to your Kudu website.
  2. [プロセス エクスプローラー] メニューを選択します。Select the Process Explorer menu.
  3. [w3wp.exe] プロセスまたは [WebJob] プロセスを右クリックします。Right-click the w3wp.exe process or your WebJob process.
  4. [Download Memory Dump] (メモリ ダンプのダウンロード) > [Full Dump] (完全ダンプ) を選択します。Select Download Memory Dump > Full Dump.

Web アプリのプロセス レベルの情報を表示するにはどうすればよいですか?How do I view process-level info for my web app?

Web アプリのプロセス レベルの情報を表示するには、次の 2 つのオプションがあります。You have two options for viewing process-level information for your web app:

  • Azure Portal で次の操作を行います。In the Azure portal:
    1. Web アプリの [プロセス エクスプローラー] を開きます。Open the Process Explorer for the web app.
    2. 詳細を表示するには、 [w3wp.exe] プロセスを選択します。To see the details, select the w3wp.exe process.
  • Kudu コンソールで次の操作を行います。In the Kudu console:
    1. Kudu の Web サイトにサインインします。Sign in to your Kudu website.
    2. [プロセス エクスプローラー] メニューを選択します。Select the Process Explorer menu.
    3. [w3wp.exe] プロセスの [プロパティ] を選択します。For the w3wp.exe process, select Properties.

アプリを参照すると、"エラー 403 - この Web アプリが停止しています" が表示されます。When I browse to my app, I see "Error 403 - This web app is stopped." 解決するにはどうすればよいですか?How do I resolve this?

このエラーは、次の 3 つの状態によって発生する可能性があります。Three conditions can cause this error:

  • Web アプリが請求の上限に達したため、サイトが使用できなくなった。The web app has reached a billing limit and your site has been disabled.
  • ポータルで Web アプリが停止された。The web app has been stopped in the portal.
  • Web アプリが、[無料] または [共有] スケール サービス プランに適用される可能性のあるリソースのクォータ制限に達した。The web app has reached a resource quota limit that might apply to a Free or Shared scale service plan.

エラーの原因を表示し、問題を解決するには、「Web アプリ: "エラー 403 – この Web アプリが停止しています"」の手順に従います。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".

各種 App Service プランのクォータと制限に関する詳細情報はどこで得られますか?Where can I learn more about quotas and limits for various App Service plans?

クォータと制限については、「App Service の制限」を参照してください。For information about quotas and limits, see App Service limits.

アイドル時間の後の最初の要求の応答時間を短縮するにはどうすればよいですか?How do I decrease the response time for the first request after idle time?

既定では、設定された期間だけアイドル状態が続くと Web アプリはアンロードされます。By default, web apps are unloaded if they are idle for a set period of time. このようにして、システムはリソースを節約できます。This way, the system can conserve resources. 欠点は、Web アプリが読み込まれて応答の処理を開始できるようにするために、Web アプリがアンロードされた後の最初の要求への応答が長くなることです。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. Azure Portal で、Web アプリに移動します。In the Azure portal, go to your web app.
  2. [アプリケーションの設定] を選択します。Select Application settings.
  3. [常時接続][On] (オン) を選択します。For Always On, select On.

失敗した要求トレースをオンにするにはどうすればよいですか?How do I turn on failed request tracing?

失敗した要求トレースをオンにするには:To turn on failed request tracing:

  1. Azure Portal で、Web アプリに移動します。In the Azure portal, go to your web app.

  2. [すべての設定] > [診断ログ] を選択します。Select All Settings > Diagnostics Logs.

  3. [失敗した要求トレース][On] (オン) を選択します。For Failed Request Tracing, select On.

  4. [保存] を選択します。Select Save.

  5. Web アプリ ブレードで [ツール] を選択します。On the web app blade, select Tools.

  6. [Visual Studio Online] を選択します。Select Visual Studio Online.

  7. 設定が [On] (オン) でない場合は、 [On] (オン) を選択します。If the setting is not On, select On.

  8. [Go] (移動) を選択します。Select Go.

  9. Web.config を選択します。Select Web.config.

  10. system.webServer で、この構成を追加します (特定の URL をキャプチャする場合)。In system.webServer, add this configuration (to capture a specific 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 秒を超える場合)。To troubleshoot slow-performance issues, add this configuration (if the capturing request is taking more than 30 seconds):

    <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. 失敗した要求トレースをダウンロードするには、ポータルで Web サイトに移動します。To download the failed request traces, in the portal, go to your website.

  13. [ツール] > [Kudu] > [Go] (移動) を選択します。Select Tools > Kudu > Go.

  14. メニューで、 [デバッグ コンソール] > [CMD] を選択します。In the menu, select Debug Console > CMD.

  15. LogFiles フォルダーを選択してから、W3SVC で始まる名前を持つフォルダーを選択します。Select the LogFiles folder, and then select the folder with a name that starts with W3SVC.

  16. XML ファイルを表示するには、鉛筆アイコンを選択します。To see the XML file, select the pencil icon.

"Worker Process requested recycle due to 'Percent Memory' limit ('メモリ比率' の制限のためにワーカー プロセスがリサイクルを要求しました)" というメッセージが表示されます。I see the message "Worker Process requested recycle due to 'Percent Memory' limit." この問題に対処するにはどうすればよいですか?How do I address this issue?

32 ビット プロセスの使用可能な最大メモリ量は (64 ビット オペレーティング システム上であっても) 2 GB です。The maximum available amount of memory for a 32-bit process (even on a 64-bit operating system) is 2 GB. 既定では、ワーカー プロセスは App Service では 32 ビットに設定されています (従来の Web アプリケーションとの互換性のため)。By default, the worker process is set to 32-bit in App Service (for compatibility with legacy web applications).

Web worker ロールで使用可能な追加のメモリを利用できるように、64 ビット プロセスに切り替えることを検討してください。Consider switching to 64-bit processes so you can take advantage of the additional memory available in your Web Worker role. これにより Web アプリの再起動がトリガーされるため、それに応じてスケジュールします。This triggers a web app restart, so schedule accordingly.

また、64 ビット環境には [基本] または [標準] サービス プランが必要なことにも注意してください。Also note that a 64-bit environment requires a Basic or Standard service plan. [無料] および [共有] プランは常に 32 ビット環境で実行されます。Free and Shared plans always run in a 32-bit environment.

詳細については、「Configure web apps in App Service (App Service での Web アプリの構成)」を参照してください。For more information, see Configure web apps in App Service.

230 秒後に要求がタイムアウトになるのはなぜですか?Why does my request time out after 230 seconds?

Azure Load Balancer には、4 分という既定のアイドル タイムアウト設定があります。Azure Load Balancer has a default idle timeout setting of four minutes. これは一般に、Web 要求のための妥当な応答時間の制限です。This is generally a reasonable response time limit for a web request. Web アプリにバックグラウンド処理が必要な場合は、Azure Web ジョブを使用することをお勧めします。If your web app requires background processing, we recommend using Azure WebJobs. Azure Web アプリは Web ジョブを呼び出し、バックグラウンド処理の完了時に通知を受けることができます。The Azure web app can call WebJobs and be notified when background processing is finished. Web ジョブを使用するための複数の方法 (キューやトリガーなど) から選択できます。You can choose from multiple methods for using WebJobs, including queues and triggers.

Web ジョブは、バックグラウンド処理用に設計されています。WebJobs is designed for background processing. Web ジョブでは、バックグラウンド処理を必要なだけ実行できます。You can do as much background processing as you want in a WebJob. Web ジョブの詳細については、「Web ジョブでのバックグラウンド タスクの実行」を参照してください。For more information about WebJobs, see Run background tasks with WebJobs.

App Service でホストされている ASP.NET Core アプリケーションが応答を停止する場合があります。ASP.NET Core applications that are hosted in App Service sometimes stop responding. この問題を解決するにはどうすればよいですか?How do I fix this issue?

以前の Kestrel バージョンでの既知の問題により、App Service でホストされている ASP.NET Core 1.0 アプリが断続的に応答を停止することがあります。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. また、"指定された CGI アプリケーションにエラーが発生し、サーバーがプロセスを停止しました" というメッセージが表示されることもあります。You also might see this message: "The specified CGI Application encountered an error and the server terminated the process."

この問題は Kestrel バージョン 1.0.2 で修正されました。This issue is fixed in Kestrel version 1.0.2. このバージョンは ASP.NET Core 1.0.3 更新プログラムに含まれています。This version is included in the ASP.NET Core 1.0.3 update. この問題を解決するには、Kestrel 1.0.2 を使用するようにアプリの依存関係を更新するようにしてください。To resolve this issue, make sure you update your app dependencies to use Kestrel 1.0.2. あるいは、ブログの投稿「ASP.NET Core 1.0 slow perf issues in App Service web apps (App Service Web アプリでの ASP.NET Core 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.

Web アプリのファイル構造内にログ ファイルが見つかりません。I can't find my log files in the file structure of my web app. どのようにしたら見つけることができますか?How can I find them?

App Service のローカル キャッシュ機能を使用する場合は、App Service インスタンスに対する LogFiles および Data フォルダーのフォルダー構造が影響を受けます。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. ローカル キャッシュが使用されている場合は、LogFiles および Data フォルダーのストレージ内にサブフォルダが作成されます。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. 各サブフォルダは、Web アプリが実行されているか、または実行された VM インスタンスに対応します。Each subfolder corresponds to a VM instance in which the web app is running or has run.

ローカル キャッシュを使用しているかどうかを判定するには、App Service の [アプリケーションの設定] タブを確認します。ローカル キャッシュが使用されている場合、アプリの設定 WEBSITE_LOCAL_CACHE_OPTIONAlways に設定されています。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.

"An attempt was made to access a socket in a way forbidden by its access permissions (アクセス許可によって禁止されている方法でソケットへのアクセスが試みられました)" というメッセージが表示されます。I see the message "An attempt was made to access a socket in a way forbidden by its access permissions." 解決するにはどうすればよいですか?How do I resolve this?

このエラーは通常、VM インスタンス上の送信 TCP 接続が使い果たされた場合に発生します。This error typically occurs if the outbound TCP connections on the VM instance are exhausted. App Service では、VM インスタンスごとに作成できる送信接続の最大数に対して制限が適用されます。In App Service, limits are enforced for the maximum number of outbound connections that can be made for each VM instance. 詳細については、「Cross-VM numerical limits (クロス VM の数値制限)」を参照してください。For more information, see Cross-VM numerical limits.

このエラーはまた、アプリケーションからローカル アドレスにアクセスしようとした場合にも発生することがあります。This error also might occur if you try to access a local address from your application. 詳細については、「Local address requests (ローカル アドレス要求)」を参照してください。For more information, see Local address requests.

Web アプリでの送信接続の詳細については、Azure Web サイトへの送信接続に関するブログの投稿を参照してください。For more information about outbound connections in your web app, see the blog post about outgoing connections to Azure websites.

Visual Studio を使用して App Service Web アプリをリモート デバッグするにはどうすればよいですか?How do I use Visual Studio to remote debug my App Service web app?

Visual Studio を使用して Web アプリをデバッグする方法を示す詳細なチュートリアルについては、「Remote debug your App Service web app (App Service Web アプリのリモート デバッグ)」を参照してください。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.