現在、アプリ (58 プロジェクト、大規模な asp.net MVC 3 フロント エンド) のビルド/デプロイ後、「アプリ プールのリサイクル」(リリース構成) 全体を通過するため、読み込みに約 15 ～ 20 秒かかります。
それが人々の答えを変えるなら、私たちはウェブファームを持っていますが、実際の問題は次のとおりです。
デプロイ後のアプリ プール リサイクルの最初の「最初のヒット」を最小限に抑えるために、メンテナンス ウィンドウが実行できない大規模なアプリケーション (私たちは 24 時間 365 日非常にアクティブな Web サイトです) で人々は何をしていますか?
その起動時間を分析するために多くのツールを使用しましたが、それを下げる方法は実際にはないようです。ユーザーに影響を与えるアプリケーションの展開。
デフォルトでは、ASP.NET アプリケーションで一度に 15 個のファイルを変更すると (FTP 経由であっても)、アプリケーション プールは自動的にリサイクルされます。ファイルの数は変更できますが、web.config ファイルと bin ファイルが変更されるとすぐにリサイクルする必要があります。したがって、私の意見では、あなたのような環境の理想的なソリューションは次のとおりです。
4 つの Web サーバー (これは任意の数です) 各サーバーには、ロード バランサーが参照する status.aspx があります。フィルターをかけます。分散キャッシュは、ユーザー エクスペリエンスの問題を維持するのに役立ちます
TeamCity を使用してこれらの 2 つのサーバーにデプロイします - 自動テストなどを実行し、満足したらそれらをファームに戻し、他の 2 つをオフラインにしてそれらにデプロイします
これはすべてスクリプト化/自動化できます。これに関する唯一の問題は、下位互換性のないスキーマ変更により、ロード バランサーがキックバックするための 20 秒間、古いバージョンのサイトと並行して新しいバージョンのサイトを実行できない可能性があることです。
これは古き良きカナリア リリースです。考慮に入れるためにhttp://continuousdelivery.com/patterns/にいくつかのパターンがあります。また、その継続的配信の本のコピーをお勧めします - 継続的配信のバイブルのようなもので、いくつかの状況から抜け出すことができました :)
最も基本的な部分では、展開の完了後にアプリケーションに対して tinyget スクリプトを実行できます。これにより、アプリケーションが「ウォームアップ」されますが、スクリプトが実行される前に顧客がサイトにアクセスすると、遅延が発生します。現在実施しているものは何ですか?導入後のどのような手順を実施していますか?
ファーム環境では展開を段階的に行うこともできるため、1 台のサーバーを負荷分散から外して更新し、展開後にそれをオンラインにし、もう 1 台を取り出して展開を完了し、ファームに再導入します。SQL Server のセットアップはどのようになっていますか? クラスター化されていますか?
最上位層に 4 台のサーバーを超える Web サイトを持つ 4 層アーキテクチャで、Blue/Green 展開戦略を運用しています。展開のために導入されたアーキテクチャが複雑であるため、「ライブ」サイトへのトラフィックを妨げずに展開する方法が必要でした。Fowler のアドバイスに従いますが、まったく同じ方法ではありませんが、各サーバーに 2 つのサイト (青と緑、または私たちの場合はサイト A とサイト B) を持つことを意味するソリューションを考え出しました。ライブ サイトには適切なホスト ヘッダーがあり、非ライブ サイトに展開してテストしたら、2 つのサイトのヘッダーを反転させて、ライブ サイトが非ライブ サイトになるようにします。 . その効果は、営業時間内に最高レベルの自信を持って実行できる堅牢な展開です。
もちろん、これにより構成と展開が少し複雑になりますが、努力する価値はあります。展開とホスト ヘッダーのスワッピングの両方をスクリプト化する必要があることは言うまでもありません。
第一に、あなたが Google やそれより大きなものを実行しているのでない限り、少数のユーザーが午前 3 時に 15 秒から 20 秒の読み込み時間で、実際にそれほど大きな影響があるのでしょうか? 時折発生する遅延を解消するために投資された労力は、2 人のユーザーが抱える 15 ～ 20 年代の不便さをはるかに上回ると思います。
残念ながら、ASP.NETを使用することの必要悪だと思います。事前にコンパイルされたサイト (コード ビハインド ファイルの代わりに .DLL) を使用すると、時間は短縮されますが、必ずしもなくなるわけではありません。
最善の方法は、ステータス通知バーのようなものを使用して、「重要なメンテナンス」中に「問題」が発生する可能性があることをユーザーに警告することです。
しかしそれでも、ユーザー エクスペリエンスの観点から言えば、サイトの読み込みに 20 秒もかかる場合は、黙って、一握りの人に自分の「遅いインターネット」のせいにさせた方がいいでしょう。遅くなるということ。
このアプローチを試すこともできます: http://weblogs.asp.net/scottgu/archive/2009/09/15/auto-start-asp-net-applications-vs-2010-and-net-4-0-series .aspx
あなたのサイトについて何も知らなくても、私の最初の考えは、サイトをより小さなサイトに分割して、個々のサイトをより速く開始できるかもしれないということです。
次に、Webファームでは、その前にある種の負荷分散デバイスがあり、展開時にマシンをプールから引き出すことができると思います。サイトを起動するためのリクエストをサイトに対して送信するまで、それらをプールに戻さないでください。マシンを取り出してデプロイし、バックアップして満足した後にリクエストを送信するボタンをクリックするように、これをスクリプト化できるはずです。
aspnet_compiler.exeデプロイ後の遅延は、「アプリ プール全体のリサイクル」ではなく、コンパイル フェーズが原因であると考えられるため、アプリケーションのプリコンパイルに使用することを検討できます。