1

私が作業しているサイトでは、2 つのクラスの変更を求めることができます。一方で、彼らは私が再構築して再展開しなければならないものを持っています. これらは「ダウンタイム」の変更としてカウントされます。これは、小さなスプラッシュ スクリーンを表示し、サイトに戻ったときにサイトを徹底的にテストするためです。

一方、彼らは私たちに多くのテキストの変更、機能のオンとオフの切り替えなどを行うように求めてきましたが、これは web.config に分離されています。展開ウィンドウの内側または外側でこれらを実行することを提案します。ファイルを編集し、変更が正しいことを確認して、作業に戻るだけです。

しかし、クライアント側の賢い人の 1 人は、web.config を編集するとアプリケーション プールがリサイクルされ、それがダウンタイムであると指摘しました。気付かなかったのですが、その通りだと思います。アプリ プールが利用できない間、アプリは「ダウン」しています。

しかし、どのくらいの期間ですか？ダウンタイム間隔でクライアントの快適さのレベルを分類するように求めているわけではありませんが、これは一般的な見方ですか? それとも、web.config の編集に 1 ～ 2 秒のアプリケーションのダウンタイムが伴うことを心配する必要はありませんか?

4

4 に答える 4

5

これまでに述べたことはすべて正しいです。

ただし、プルする値がキャッシュされていない限り、このダウンタイムを回避する方法があります。

.config ファイルの一部を別のファイルに移植できます。これにより、アプリケーション プールがリサイクルされなくなります。

web.config ファイルでは次のようになります。

<appSettings file="moresettings.config"></appSettings>

次に、外部ファイルは次のようになります。

<?xml version="1.0" encoding="utf-8" ?>
<appSettings>   
<add key="SOMEKEY" value="MYVALUE"/>
</appSettings>
于 2009-12-28T18:04:27.067 に答える
3

ダウンタイムが心配で、これが頻繁に発生する場合は、これらの設定をデータベースに移動することを検討してください。

とはいえ、あなたの場合のダウンタイムは最小限に抑えられます。web.config ファイルを保存すると、アプリ プールがリサイクルされます。これは数ミリ秒のことです。

于 2009-12-28T17:52:05.127 に答える
3

IIS は通常、アプリケーション プールをそれ自体でリサイクルします。これらのリサイクルが問題にならないのであれば、これも心配する必要はありません。

ユーザーは、「サービスを利用できません」というエラーを受け取るべきではありません。

于 2009-12-28T17:54:10.423 に答える
2

前述のように、IIS は実際にアプリケーション プールをリサイクルしています。ただし、これは完全な iisreset を実行するほど悪くはありません。ユーザーは「サービスを利用できません」というメッセージを受け取るべきではありません。Web サーバーはまだオンラインで要求を処理しているため、AppPool が再起動するのを待つ必要があるため、エラーが発生します。つまり、この瞬間にアクセスするユーザーの応答時間が非常に長くなります。これはもちろん、公開 Web サイトを持っていて訪問者を遠ざけている場合には問題になる可能性があります。

AppPool リサイクルのその他の副作用は、iisreset と同じです。私の間違いでなければ、InProc セッション キャッシュをフラッシュし、Application_Start イベントを実行します。

したがって、比較的無害ですが、ダウンタイムとして扱います。

于 2009-12-28T18:09:03.517 に答える