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

[アーティクル]
07/17/2023

注:

以下のガイドラインの一部は、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 アプリのイベントログを表示するには:

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

web アプリのユーザーモードメモリダンプをキャプチャ操作方法?

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

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

操作方法 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設定を変更するには:

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

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

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

Azure portalで、Web アプリに移動します。
[すべての設定][診断ログ] > を選択します。
[ 失敗した要求トレース] で、[オン] を選択します。
[保存] を選択します。
[Web アプリ] ブレードで、[ ツール] を選択します。
[ Visual Studio Online] を選択します。
設定が [オン] でない場合は、[ オン] を選択します。
[Go]を選択します。
[Web.config] を選択します。

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>

パフォーマンスの低下の問題をトラブルシューティングするには、この構成を追加します (キャプチャ要求に 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>

失敗した要求トレースをダウンロードするには、ポータルで Web サイトに移動します。
[ツール]>[KuduGo] の順に>選択します。
メニューで、[デバッグコンソールCMD] を選択します>。
LogFiles フォルダーを選択し、W3SVC で始まる名前のフォルダーを選択します。
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 フィードバックコミュニティに製品フィードバックを送信することもできます。

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