w3wp メモリにのみ存在するため、w3wp 所有者プロセスがリサイクルされると、すべての InProc セッション データが常に失われることを理解しています。
リサイクルがプロセスの外部で発生したときにセッションデータをキャッシュし、セッションが戻ってきたときにセッションを再注入(および再構築)できるかどうか疑問に思いました。そうすれば、必要に応じて状態サーバーのような外部化の信頼性を備えた InProc の速度を得ることができます。これは可能ですか?
w3wp メモリにのみ存在するため、w3wp 所有者プロセスがリサイクルされると、すべての InProc セッション データが常に失われることを理解しています。
リサイクルがプロセスの外部で発生したときにセッションデータをキャッシュし、セッションが戻ってきたときにセッションを再注入(および再構築)できるかどうか疑問に思いました。そうすれば、必要に応じて状態サーバーのような外部化の信頼性を備えた InProc の速度を得ることができます。これは可能ですか?
いいえ、これは不可能です。インプロセスのセッション状態またはキャッシュを「ウォームアップ」する API はありません。とにかく、そのような解決策は信頼できません。アプリが最後に行ったのが現在のセッション状態のエクスポートであるとは保証できませんでした。
Web アプリケーションと同じホストでアウト プロセス状態サーバーを使用できます。その後、Web アプリケーションは自由にリサイクルでき、状態情報はそのまま維持されます。これは、SQL Server を使用してセッションを管理するよりもかなり高速です。SQL のオーバーヘッドや別のマシンへのネットワーク転送に対処する必要がないためです。処理中のセッション状態よりも悪い唯一の方法は、データがプロセス境界を越えてマーシャリングしますが、急速に変化する大量のセッション データがない限り、これはまったく目立ちません。
Microsoft Project Code Named "Velocity"やScaleOut Software の SessionServer (とりわけ)などの代替手段もあり、サーバー ファーム内のサーバー間でセッション状態を維持したり、キャッシュを同期したりできる分散型キャッシュ メカニズムを提供します。 SQL Server の使用に。
別のユーザーが投稿したこととは反対に、可能であれば ViewState を使用してセッション データを保存しません。1 つには、これは真のセッション状態ではありません。ユーザーが前後に移動すると、失われる可能性があります。第二に、それはかなり安全ではありません。第 3 に、悪用すると大量のページが肥大化します。
意図する場合は、セッション状態に SQL Server を使用する必要があります。必要なのは、ホスト プロセスの完全な終了から回復できるセッションです。inproc も stateserver も、ダウンするとすべてのデータが失われるため、サポートしていません。独自の状態メソッドを作成することもできますが、それは面倒です。やりたい場合の手順は次のとおりです。
やりたいことは、セッションをまったく使用せず、ViewState にもっと依存することです。トラフィックの多いサイトがある場合、これはワークロードをクライアントにプッシュする良い方法です。
ワーカー プロセスがリサイクルされた場合に、そのデータに基づいてセッションを再作成できるように、Cookie (または ViewState) に十分な情報を保存できる場合があります。
または、セッションの一部を保存する独自の状態サーバー (Windows サービスなど) を作成し、リモート処理などを介して Web アプリからこのサービスにアクセスすることもできます。