私は今、Azure 用の新しい Web アプリケーションを作成している最中です。
しばらく (30 分以上) サイトにアクセスしないと、最初のアクセス時に読み込みに時間がかかる (20 秒以上) ことに気付きました。これは、Azure がアプリケーションをコンパイルする必要があるためだと思います。長時間アイドリングした後にアプリケーションを遵守する必要がないようにする方法はありますか。または、何らかの方法で Web アプリケーションをローカルで事前にコンパイルしてから、Azure にデプロイして、サーバーでコンパイルする必要がないようにしますか?
VS 2012、Web アプリケーション (Web フォーム)、および Web Deploy を使用しています
ここから私の Web サイトにアクセスできます。
残念ながら、Azure Web サイトでこれを回避する方法はありません。あなたが言ったように、IIS は要求主導型の Web サーバーであり、要求されたときにのみ処理を行うという事実によるものです。したがって、IIS ワーカー プロセスは、このワーカー プロセスでホストされているサイトに要求が到着したときにのみ起動します。
VS2012 と Web デプロイを使用している場合は、おそらく既にコードをコンパイルしています。.Net では、このコンパイル手順は、CPU に依存しない IL (中間言語) への途中までしか行わないため、ワーカー プロセスはこれを取得して、そのマシンで実行できるネイティブ コードに変換する必要があります。そのため、サイトの読み込みに時間がかかっています。
彼らは、IIS 8 に含まれていた IIS 7.5 でウォームアップ モジュール (アプリケーションの初期化) の出荷を開始しました。これは、ネイティブ モジュールであるため、Azure Web サイトでは残念ながら、初期化の重いサイトでこの問題を解決するために利用できません。それを使用したい場合は、Azure クラウド サービスまたは仮想マシンに切り替えてサイトを実行する必要があります。
私が知っている人々が使用する他の代替手段は、pingdom などのクラウド監視サービスを使用することです。これは、ワーカー プロセスを維持するサイト上のページに対して明らかに継続的に要求を行います。理想からかけ離れた最後の代替案は、ページを維持するためにページにリクエストを行う簡単なスクリプトをどこかに置くことです。
ただし、Web サイトの人気が高まった場合は、人々が Web サイトを訪れているという事実だけでワーカー プロセスが維持されるため、これらの手順は必要ありません。
Google Page Speed であなたのサイトを実行しました: https://developers.google.com/speed/pagespeed/insights#url=http_3A_2F_2Fffinfo.azurewebsites.net_2F&mobile=false
「共有」WebSite インスタンスの速度/パフォーマンスが気になる場合は、そこにリストされている項目のいくつかを修正する必要があります。375kb の巨大な背景を持つことはおそらく最良のアイデアではありません...そして圧縮さえされていません.
可能であれば、クラウド サービスの「非常に小さい」インスタンスに移動すると、多くの追加機能を最適化できます (ASP.NET モジュールを無効にする、ヘッダーを削除する、圧縮を制御する、クライアント キャッシュを制御する)。あなたの目標は、人気のあるサイトを持つことですよね?...すぐに始めましょう :)