Web アプリケーションのセッション タイムアウトは通常、アイドル時間、つまりユーザーがアプリケーションを操作していない時間を示します。
では、5 分ごとにリクエストを送信する自動化されたスクリプトが作成された場合、そのユーザーのセッションは際限なく続くのではないでしょうか? この場合、このアプローチはアプリケーションに大きな負荷をかけ、長期的にはパフォーマンスに影響を与えませんか?
サーバーへの自動呼び出しを実行すると、たとえば AJAX 要求を介して、セッションが維持されます。通常、それがポイントです。これの興味深い副作用は、リクエストが予測どおりに定期的に発生する場合、それを「ping」として使用して、ユーザーのブラウザがまだ開いているかどうかを判断できることです。1 つまたは 2 つの ping に失敗した場合は、セッションをタイムアウトにするよりも早くセッションを閉じて、実際にリソースを解放することができます。
セッション データに大きく依存するアプリケーションに対して、同様のことを行いました。
私がしたことは、IIS のタイムアウトを比較的低い値 (たとえば 10 分) に設定してから、5 分ごとに空白のページに ping を送信する時間指定された AJAX 呼び出しを行うことでした。
このオーバーヘッドは実際にはかなり低く、空白のページをリクエストするだけで、ユーザーがブラウザーを閉じるとセッションは 10 分で終了します。
はい、はい。
これが、Web 用のアプリケーションを作成する場合、サーバー側のセッションを使用せずにアプリケーションを実装する方法を本当に見つけたいと考える理由です。通常、Cookie を使用して同じ機能を実装する方法を見つけることができます。その場合、セッション データはクライアント側にあるため、セッション データが永続的にアクティブであるかどうかは気にしません。
セッションをできるだけ小さく保ちたい。そうは言っても、誰もがそれを始めれば、もちろん、セッションなしでアプリケーションをロードします。ユーザーが強制的にそうする必要があると思われる場合は、アプリケーションに重要な機能が欠けているか、ユーザーに何かを強制しているため、その理由を考えてください。
それにもかかわらず、多くのユーザーが同時にアクティブになることを期待している場合は、単一のサーバーでは不可能なほど多くの場合、セッションがプロセス外になることになります。セッションが Sql Server にある場合、それは単に保存されたデータであるため、その場合、メモリ使用量については話していません。
ええと...「場合による」と思います。最初に自問すべき質問は、セッションが必要かどうかです。
自動化されたプロセスを使用している場合、セッションを実際に使用する必要はないと思います。
その場合は、オフにするか、気にしないでください。
セッションテーブルは少し大きくなると思いますが、一方で、セッションを破棄して再作成することはありません。これがどのようにアプリケーションに「重い負荷をかける」のかわかりません。アプリケーション自体と、セッション状態を維持するために使用されるメモリの量に依存すると思います。
ユーザーがブラウザを開いている限り、ユーザーのセッションを際限なく続けることができます。セッションを長時間維持する必要がある場合は、メモリではなく DB を介してセッションを追跡することもできます。
また、無期限に開いているセッションが心配な場合は、セッションが開いたときからタイムアウトを実装し、アイドル時間が延長された場合に実装できます。