次の方法で共有

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

  • [アーティクル]

Note

以下のガイドラインのいくつかは、Windows または Linux App Services でのみ有効な場合があります。 たとえば、Linux App Services は既定で 64 ビット モードで動作します。

この記事では、Azure App Service の Web アプリ機能でのアプリケーション パフォーマンスの問題に関するよくあるご質問 (FAQ) への回答を示します。

この記事で Azure の問題に対処できない場合は、MSDN および Stack Overflow の Azure 関連フォーラムを参照してください。 問題をこれらのフォーラムに投稿するか、または Twitter の @AzureSupport に投稿できます。 Azure サポート要求を送信することもできます。 サポート要求を送信するには、[Azure サポート] ページで [サポートを受ける] を選択します。

すべての Web アプリが停止されている場合でも、App Service プランで CPU/メモリ使用量が表示されるのはなぜですか?

Azure アプリ サービスには、セキュリティ更新プログラム、SCM コンソールの可用性、アプリケーションの監視、認証、Web アプリのその他の多くの重要な機能など、いくつかのプラットフォーム操作と機能を処理する継続的なシステム プロセスが必要です。

実行中の Web アプリがない場合や、App Service プランに Web Apps が含まれている場合でも、App Service プランでシステム プロセスが実行されます。

プラットフォーム プロセスは最小限のリソース (CPU、メモリ、ディスク領域など) を消費するため、App Service プランの容量計画、監視、自動スケーリング トリガーの構成時にも同じ内容を考慮する必要があります。

アプリが低速なのはなぜですか?

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

CPU 使用量が多いシナリオをトラブルシューティングするにはどうすればよいですか?

CPU 使用量が多い一部のシナリオでは、アプリが実際により多くのコンピューティング リソースを必要としている可能性があります。 その場合は、アプリケーションが必要なすべてのリソースを取得できるように、より高いサービス階層へのスケーリングを検討してください。 その他の場合、CPU 使用量の多さは、不適切なループまたはコーディング方法によって発生している可能性があります。 CPU 使用量が増えている原因の調査は 2 つの部分からなるプロセスです。 最初にプロセス ダンプを作成し、次にプロセス ダンプを分析します。 詳細については、「Capture and analyze a dump file for high CPU consumption for Web Apps (Web アプリの増加した CPU 使用量のためのダンプ ファイルの取得と分析)」を参照してください。

メモリ使用量が多いシナリオをトラブルシューティングするにはどうすればよいですか?

メモリ使用量が多い一部のシナリオでは、アプリが実際により多くのコンピューティング リソースを必要としている可能性があります。 その場合は、アプリケーションが必要なすべてのリソースを取得できるように、より高いサービス階層へのスケーリングを検討してください。 その他の場合、コード内のバグがメモリ リークの原因になることがあります。 また、コーディング方法によってもメモリ使用量が増えることがあります。 メモリ使用量が多い原因の調査は 2 つの部分からなるプロセスです。 最初にプロセス ダンプを作成し、次にプロセス ダンプを分析します。 Azure サイト拡張機能ギャラリーのクラッシュ診断は、これらの手順の両方を効率的に実行できます。 詳細については、「Capture and analyze a dump file for intermittent high memory for Web Apps (Web アプリの断続的な増加したメモリ使用量のためのダンプ ファイルの取得と分析)」を参照してください。

PowerShell を使用して App Service Web アプリを自動化するにはどうすればよいですか?

PowerShell コマンドレットを使用すると、App Service Web アプリを管理および維持できます。 ブログの投稿「Automate web apps hosted in Azure App Service by using PowerShell (PowerShell を使用して Azure App Service でホストされた Web アプリを自動化する)」では、Azure Resource Manager ベースの PowerShell コマンドレットを使用して一般的なタスクを自動化する方法について説明しています。 このブログの投稿にはまた、さまざまな Web アプリ管理タスクのサンプル コードも含まれています。 すべての App Service Web アプリ コマンドレットの説明と構文については、「Az.Websites」を参照してください。

Web アプリのイベント ログを表示するにはどうすればよいですか?

Web アプリのイベント ログを表示するには:

  1. Kudu の Web サイト (https://*yourwebsitename*.scm.azurewebsites.net) にサインインします。
  2. メニューで、[デバッグ コンソール]>[CMD] を選択します。
  3. LogFiles フォルダーを選びます。
  4. イベント ログを表示するには、eventlog.xml の横にある鉛筆アイコンを選択します。
  5. ログをダウンロードするには、PowerShell コマンドレット Save-AzureWebSiteLog -Name webappname を実行します。

Web アプリのユーザーモードのメモリ ダンプをキャプチャするにはどうすればよいですか?

Web アプリのユーザーモードのメモリ ダンプをキャプチャするには:

  1. Kudu の Web サイト (https://*yourwebsitename*.scm.azurewebsites.net) にサインインします。
  2. [プロセス エクスプローラー] メニューを選択します。
  3. [w3wp.exe] プロセスまたは [WebJob] プロセスを右クリックします。
  4. [Download Memory Dump] \(メモリ ダンプのダウンロード)>[Full Dump] \(完全ダンプ) を選択します。

Web アプリのプロセス レベルの情報を表示するにはどうすればよいですか?

Web アプリのプロセス レベルの情報を表示するには、次の 2 つのオプションがあります。

  • Azure portal で、次の操作を行います。
    1. Web アプリの [プロセス エクスプローラー] を開きます。
    2. 詳細を表示するには、[w3wp.exe] プロセスを選択します。
  • Kudu コンソールで次の手順を実行します。
    1. Kudu の Web サイト (https://*yourwebsitename*.scm.azurewebsites.net) にサインインします。
    2. [プロセス エクスプローラー] メニューを選択します。
    3. [w3wp.exe] プロセスの [プロパティ] を選択します。

アプリを参照すると、「エラー 403 - この Web アプリは停止しています」と表示されます。これを解決操作方法?

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

  • Web アプリが請求の上限に達したため、サイトが使用できなくなった。
  • ポータルで Web アプリが停止された。
  • Web アプリが、[無料] または [共有] スケール サービス プランに適用される可能性のあるリソースのクォータ制限に達した。

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

各種 App Service プランのクォータと制限に関する詳細情報はどこで得られますか?

クォータと制限については、「App Service の制限」を参照してください。

アイドル時間の後の最初の要求の応答時間を短縮するにはどうすればよいですか?

既定では、Web アプリが一定期間アイドル状態の場合はアンロードされます。 このようにして、システムはリソースを節約できます。 欠点は、Web アプリが読み込まれて応答の処理を開始できるようにするために、Web アプリがアンロードされた後の最初の要求への応答が長くなることです。 [基本] および [標準] サービス プランでは、アプリを常に読み込まれた状態にするために、[常時接続] 設定をオンにすることができます。 これにより、アプリがアイドル状態になった後の読み込み時間が長くなることはなくなります。 [常時接続] 設定を変更するには:

  1. Azure Portal で、Web アプリに移動します。
  2. [構成] を選択します。
  3. [全般設定] を選択します。
  4. [常時接続] の [On] \(オン) を選択します。

失敗した要求トレースをオンにするにはどうすればよいですか?

失敗した要求トレースを有効にするには、次の手順に従います。

  1. Azure Portal で、Web アプリに移動します。

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

  3. [失敗した要求トレース] の [On] \(オン) を選択します。

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

  5. Web アプリ ブレードで [ツール] を選択します。

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

  7. 設定が On でない場合は、 On を選択します。

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

  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. 失敗した要求トレースをダウンロードするには、ポータルで Web サイトに移動します。

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

  14. メニューで、[デバッグ コンソール]>[CMD] を選択します。

  15. LogFiles フォルダーを選択してから、W3SVC で始まる名前を持つフォルダーを選択します。

  16. XML ファイルを表示するには、鉛筆アイコンを選択します。

"ワーカー プロセスが 'Percent Memory' の制限によりリサイクルを要求しました" というメッセージが表示されます。この問題操作方法対処しますか?

32 ビット プロセスの使用可能な最大メモリ量は (64 ビット オペレーティング システム上であっても) 2 GB です。 既定では、ワーカー プロセスは App Service では 32 ビットに設定されています (従来の Web アプリケーションとの互換性のため)。

Web worker ロールで使用可能な追加のメモリを利用できるように、64 ビット プロセスに切り替えることを検討してください。 このアクションにより Web アプリの再起動がトリガーされるため、それに応じてスケジュールします。

また、64 ビット環境には [基本] または [標準] サービス プランが必要なことにも注意してください。 [無料] および [共有] プランは常に 32 ビット環境で実行されます。

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

230 秒後に要求がタイムアウトになるのはなぜですか?

Azure Load Balancer には、4 分という既定のアイドル タイムアウト設定があります。 この設定は一般的にウェブ リクエストのための妥当な応答時間の制限です。 そのため、アプリケーションが約 240 秒以内 (Windows アプリでは 230 秒、Linux アプリでは 240 秒) に応答が返されない場合、App Service はクライアントにタイムアウトを返します。　Web アプリにバックグラウンド処理が必要な場合は、Azure Web ジョブを使用することをお勧めします。 Azure Web アプリは Web ジョブを呼び出し、バックグラウンド処理の完了時に通知を受けることができます。 Web ジョブを使用するための複数の方法 (キューやトリガーなど) から選択できます。

Web ジョブは、バックグラウンド処理用に設計されています。 Web ジョブでは、バックグラウンド処理を必要なだけ実行できます。 Web ジョブの詳細については、「Web ジョブでのバックグラウンド タスクの実行」を参照してください。

App Service でホストされている ASP.NET Core アプリケーションが応答を停止する場合があります。 この問題を解決するにはどうすればよいですか?

以前の Kestrel バージョンでの既知の問題により、App Service でホストされている 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 (App Service Web アプリでの ASP.NET Core 1.0 の低速なパフォーマンスの問題)」で説明されている 2 つの対処法のいずれかを使用することもできます。

Web アプリのファイル構造内にログ ファイルが見つかりません。 どのようにしたら見つけることができますか?

App Service のローカル キャッシュ機能を使用する場合は、App Service インスタンスに対する LogFiles および Data フォルダーのフォルダー構造が影響を受けます。 ローカル キャッシュが使用されている場合は、LogFiles および Data フォルダーのストレージ内にサブフォルダが作成されます。 これらのサブフォルダは、"一意識別子" + タイムスタンプという名前付けパターンを使用します。 各サブフォルダは、Web アプリが実行されているか、または実行された VM インスタンスに対応します。

ローカル キャッシュを使用しているかどうかを確認するには、App Service アプリケーション設定 タブを確認します。ローカル キャッシュを使用している場合、アプリ設定 WEBSITE_LOCAL_CACHE_OPTION は Alwaysに設定されます。

ローカル キャッシュを使用せず、この問題が発生している場合は、サポート リクエストを送信してください。

"アクセス許可によって禁止されている方法でソケットにアクセスしようとしました" というメッセージが表示されます。このエラー操作方法解決しますか?

このエラーは通常、VM インスタンス上の送信 TCP 接続が使い果たされた場合に発生します。 App Service では、VM インスタンスごとに作成できる送信接続の最大数に対して制限が適用されます。 詳細については、「Cross-VM numerical limits (クロス VM の数値制限)」を参照してください。

このエラーはまた、アプリケーションからローカル アドレスにアクセスしようとした場合にも発生することがあります。 詳細については、「Local address requests (ローカル アドレス要求)」を参照してください。

Web アプリでの送信接続の詳細については、Azure Web サイトへの送信接続に関するブログの投稿を参照してください。

Visual Studio を使用して App Service Web アプリをリモート デバッグするにはどうすればよいですか?

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

お問い合わせはこちらから

質問がある場合やヘルプが必要な場合は、サポート要求を作成するか、Azure コミュニティ サポートにお問い合わせください。 Azure フィードバック コミュニティに製品フィードバックを送信することもできます。