次の方法で共有

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 Appsが停止しても、App Serviceプランで CPU/メモリ使用量が表示されるのはなぜですか?

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

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

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

アプリの速度が遅くなるのはなぜですか?

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

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

CPU 消費量の多いシナリオでは、アプリに本当により多くのコンピューティング リソースが必要になる場合があります。 その場合は、アプリケーションが必要なすべてのリソースを取得できるように、より高いサービス レベルにスケーリングすることを検討してください。 また、CPU の消費量が多い場合は、不適切なループやコーディングプラクティスが原因である可能性があります。 CPU 消費量の増加を引き起こしている内容に関する分析情報を得ることは、2 部構成のプロセスです。 まず、プロセス ダンプを作成してから、プロセス ダンプを分析します。 詳細については、「Web Appsの CPU 消費量が多いダンプ ファイルをキャプチャして分析する」を参照してください。

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

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

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

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. メニューで、[デバッグ コンソール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 プロセスまたは 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 アプリは、無料または共有スケール サービス プランに適用される可能性があるリソース クォータ制限に達しました。

エラーの原因を確認し、問題を解決するには、「エラー 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. [すべての設定][診断ログ] > を選択します。

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

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

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

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

  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. [ツール]>[KuduGo] の順に>選択します。

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

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

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

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

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

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

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

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

230 秒後に要求がタイムアウトする理由

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

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

ASP.NET CoreでホストされているアプリケーションApp Service応答を停止することがあります。 この問題操作方法解決しますか?

以前の 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 の遅いパフォーマンスの問題 ASP.NET Coreブログ記事で説明されている 2 つの回避策のいずれかを使用することもできます。

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

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

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

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

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

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

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

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

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

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

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

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