Azure でのWeb Appsのアプリケーション パフォーマンスに関する FAQ

注意

以下のガイドラインの一部は、Windowsまたは Linux App Services でのみ機能する場合があります。 たとえば、Linux App Services は既定で 64 ビット モードで実行されます。

この記事では、Azure App ServiceのWeb Apps機能に関するアプリケーションパフォーマンスの問題についてよく寄せられる質問 (FAQ) に対する回答を示します。

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

アプリが遅いのはなぜですか?

複数の要因によって、アプリのパフォーマンスが低下する可能性があります。 トラブルシューティングの手順の詳細については、「 Web アプリのパフォーマンス低下のトラブルシューティング」を参照してください。

CPU 消費量の高いシナリオのトラブルシューティングを操作方法しますか?

一部の CPU 消費の高いシナリオでは、アプリでは実際により多くのコンピューティング リソースが必要になる場合があります。 その場合は、アプリケーションが必要なすべてのリソースを取得するように、より高いサービス レベルにスケーリングすることを検討してください。 それ以外の場合は、CPU 使用率が高い場合は、ループが正しくないか、コーディングプラクティスによって発生する可能性があります。 CPU 消費量の増加を引き起こしているものについての洞察を得ることは、2 部構成のプロセスです。 まず、プロセス ダンプを作成し、プロセス ダンプを分析します。 詳細については、「ダンプ ファイルをキャプチャして分析して、Web Appsの CPU 消費量を高くする」を参照してください。

操作方法メモリ消費量の高いシナリオのトラブルシューティングを行いますか?

一部のメモリ消費量の高いシナリオでは、アプリでは実際により多くのコンピューティング リソースが必要になる場合があります。 その場合は、アプリケーションが必要なすべてのリソースを取得するように、より高いサービス レベルにスケーリングすることを検討してください。 また、コード内のバグによってメモリ リークが発生する可能性があります。 コーディングの手法により、メモリ消費量が増加する可能性もあります。 高いメモリ消費量を引き起こしているものについての洞察を得ることは、2 部構成のプロセスです。 まず、プロセス ダンプを作成し、プロセス ダンプを分析します。 Azure Site Extension Gallery の Crash Diagnosticr は、これらの両方の手順を効率的に実行できます。 詳細については、「ダンプ ファイルをキャプチャして分析し、Web Appsの断続的な高メモリを得る」を参照してください。

PowerShell を使用して web アプリApp Service自動化操作方法?

PowerShell コマンドレットを使用して、App Service Web アプリを管理および管理できます。 ブログ記事では、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. メニューの [Debug ConsoleCMD > ] を選択します。
  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 プロセスまたは Web ジョブ プロセスを右クリックします。
  4. [メモリ ダンプフルル ダンプ > のダウンロード] を選択 します

操作方法自分の Web アプリのプロセス レベルの情報を表示しますか?

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

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

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

次の 3 つの条件により、このエラーが発生する可能性があります。

  • Web アプリが課金制限に達し、サイトが無効になっています。
  • ポータルで Web アプリが停止されました。
  • Web アプリが、Free または Shared Scale サービス プランに適用される可能性があるリソース クォータの制限に達しました。

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

さまざまなApp Serviceプランのクォータと制限の詳細については、どこで確認できますか?

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

アイドル時間後の最初の要求の応答時間を短縮操作方法?

既定では、一定の期間アイドル状態の Web アプリはアンロードされます。 これにより、システムはリソースを節約できます。 欠点は、Web アプリを読み込んで応答の提供を開始できるように、Web アプリがアンロードされた後の最初の要求に対する応答が長くなることです。 Basic サービス プランと Standard サービス プランでは、Always On 設定をオンにして、アプリを常に読み込むことができます。 これにより、アプリがアイドル状態になった後の読み込み時間が長くなります。 Always On 設定を変更するには:

  1. Azure portalで、Web アプリに移動します。
  2. 構成の 選択
  3. [ 全般設定] を選択します。
  4. [Always On] で [オン] を選択します。

失敗した要求トレース操作方法有効にしますか?

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

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

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

  3. [失敗した要求トレース] で 、[オン] を選択します。

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

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

  6. [オンラインVisual Studio] を選択します。

  7. 設定が [オン] でない場合は、[ オン] を選択します。

  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. ToolsKuduGo > > を選択 します

  14. メニューの [Debug ConsoleCMD > ] を選択します。

  15. LogFiles フォルダーを選択し、W3SVC で始まる名前のフォルダーを選択します。

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

"Worker Process が "%Memory" 制限のためにリサイクルを要求しました" というメッセージが表示されます。 この問題に対処操作方法?

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

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

また、64 ビット環境には Basic または Standard のサービス プランが必要であることにも注意してください。 Free プランと Shared プランは、常に 32 ビット環境で実行されます。

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

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

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

WebJobs はバックグラウンド処理用に設計されています。 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 を使用するようにアプリの依存関係を更新してください。 または、App Service Web アプリの 1.0 の低速 perf の問題 ASP.NET Coreブログ投稿で説明されている 2 つの回避策のいずれかを使用することもできます。

Web アプリのファイル構造に自分のログ ファイルが見つかりません。 それらを見つけるにはどうすればよいですか?

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

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

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

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

このエラーは、通常、VM インスタンス上の送信 TCP 接続が使い果たされた場合に発生します。 App Serviceでは、各 VM インスタンスに対して行うことができる送信接続の最大数に制限が適用されます。 詳細については、 VM 間の数値制限に関するページを参照してください。

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

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

Visual Studioを使用してApp Service Web アプリをリモート デバッグ操作方法?

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

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

質問がある場合やヘルプが必要な場合は、サポート要求を作成するか、Azure コミュニティ サポートにお問い合わせください。