しばらくアイドル状態になった後、AzureアプリサービスのWebサイトの応答時間が遅くなる
ここ数週間、MVCアプリケーションの最初のリクエストに対する応答が非常に遅いパフォーマンスの問題を調査してきました。最初のリクエストは30〜45秒、新しいビューはそれぞれ3秒です。私たちのMVCアプリケーションは、同じサーバー上にあるOData API（Web API）を使用しています。 MVCアプリケーションと同じパフォーマンスの問題に加えて、エンティティフレームワークバージョン6への最初のクエリは6秒で実行され、新しいクエリは後続のクエリより200ミリ秒遅く実行されます。
要件を満たすために、既知のEfクエリをすべて実行し、Global.asaxのApplication_StartからすべてのMVC/APIエンドポイントにアクセスすることを選択しました。これは少なくとも数時間は問題なく動作するようですが、しばらく使用しないと、すべてのMVCビューへの最初のリクエストが3〜5秒で応答します。
Webサイトを「常にオン」に設定しましたが、IISログまたはApplication_Startに追加したログには何も見つかりませんでした。そのため、アプリケーションは少なくともリサイクルされていないようです。何らかの種類のIISキャッシュがクリアされているか、またはおそらくEfキャッシュがいくつかあると思いますか？）提案は大歓迎です。
Webアプリの「常にオン」設定を有効にする必要があります。
あなたはportal.Azure.comからそれを行うことができます->あなたのサイトのブレード->すべての設定->アプリケーション設定->常にオン
詳細はこちらをご覧ください： https://Azure.Microsoft.com/en-us/documentation/articles/web-sites-configure/
Always Onが無効になっている場合、非アクティブ状態が20分間続くと、同じApp Serviceプランで実行されている可能性のある他のサイトのためにリソースを解放するために、サイトが停止されます。
私は同じ問題を抱えていましたが、残念ながら、「Always On」設定は無料および共有の価格階層では利用できません。アンロードしないようにWebアプリを暖かく保つ簡単な方法は、WepアプリのURLに対してApplication Insightsのpingテストを15分間隔で設定することです。それを見つける方法のウォークスルー ここ
簡単な回避策は、webAppのアイドル状態を回避するために頻繁にWebサイトにpingするバックグラウンドジョブを作成することです。
または
Sql Server dbプランをアップグレードして、それに応じてテストしてください。
幸運とこれがお役に立てば幸いです。
失敗したリクエストのロギングを有効にして、この問題を調査しようとしましたか？
Azure Portal→アプリサービス→監視→診断ログ→失敗した要求のトレース（オン）
web.configのipSecurityセクションを使用してアプリケーションへのアクセスを制限することによって引き起こされた同様の問題が発生しました。この方法でアクセスを制限した場合は、アプリサービスのIPをホワイトリストに登録する必要があります。