21

私はすでにこのテーマについて検索を行っており、同じデータを何度も見つけました。つまり、3 つの異なるタイプのセッションのレビューです。(InProc、Sql、StateServer) しかし、私の質問は性質が異なります。

具体的には、そもそも組み込みの .NET セッションを使用する利点と欠点は何ですか?

私が質問する理由は次のとおりです。仲間の .NET 開発者から、組み込みの Microsoft セッションを決して使用しないように言われました。全くない。カスタムのセッション状態プロバイダーを作成することすらありません。これに対する彼の理由は次のとおりです。IIS でセッションを有効にすると、すべての要求が同期的に発生するからです。彼は、セッションを有効にすると Web サーバーのパフォーマンスが低下すると述べています。

これに対する彼の解決策は、自分でセッションを作成することです。これは、必要なすべての値を格納し、データベースの内外でシリアル化されるクラスです。彼は、これを参照する一意の ID を Cookie またはクエリ文字列変数に格納することを勧めています。私たちの環境では、作成するすべてのページが Web ファーム上にあり、Oracle を使用しているため、DB を使用してセッションを保存することが必須です。その部分には同意します。

組み込みのセッションを使用すると、自家製のセッションよりもパフォーマンスが低下しますか? これにセキュリティ上の懸念はありますか？

結論から言うと、メリット/デメリットは？

答えてくれてありがとう！

4

8 に答える 8

17

私の経験では、適切に使用すれば、セッションは状態を管理する優れた手段です。ただし、多くの開発者が共有する「セッションを決して使用しない」という感情を引き起こし、誤用されることがよくあります。

私と他の多くの開発者は、セッションを誤って使用してデータベースから大量のデータを保存し、「旅行を節約」したときに重大なパフォーマンスの問題に遭遇しました。これは悪いです。セッションごとに 2000 のユーザー レコードを保存すると、2 人以上のユーザーがアプリケーションを使用する場合、Web サーバーが機能しなくなります。セッションをデータベース キャッシュとして使用しないでください。

ただし、セッションごとに整数を格納することはまったく問題ありません。現在のユーザーがアプリケーションをどのように使用しているか (ショッピング カートを考えてください) を表す少量のデータは、セッション状態をうまく利用します。

私にとっては、状態を管理することがすべてです。正しく行われれば、セッションは状態を管理するための多くの優れた方法の 1 つになります。ただし、状態をどのように管理するかについては、最初に決定する必要があります。ほとんどの場合、誰かが「セッションに何かを投げる」ことを決定したときに問題に遭遇します。

この記事は、アウト プロセス モードを使用する際に非常に役立つことがわかりました。また、自分では思いつかなかったヒントがいくつか含まれています。たとえば、クラスをシリアライズ可能としてマークするのではなく、そのプリミティブ データ型メンバーを別のセッション変数に格納してからオブジェクトを再作成すると、パフォーマンスが向上します。

于 2009-04-28T18:16:01.063 に答える
7

まず、あなたの同僚は、DB を利用した独自のセッション管理システムを実装していますが、データベースに格納された組み込みのセッション状態を使用する場合と比較して、これがどのような利点があるかわかりません (MS SQL がデフォルトであり、代わりに Oracle を使用しない理由はありません)。

彼のソリューションは組み込みのソリューションよりも優れていますか? ありそうもない。それはあなたにとって最初の仕事です。その理由を簡単に説明します。ID を保存するために Cookie を使用しているとします。Cookie をオフにするユーザーにどのように対処しますか? ASP.Net のセッション状態を使用している場合は、クエリ文字列の使用にフォールバックするため、問題はありません。同僚のアイデアを使用して、自分でロールバックする必要があります。

セッション状態を保持する必要があるかどうかについては、非常に有効な質問があります。セッション状態をまったく必要としないようにアプリケーションを設計できれば、スケーリングとテストがはるかに簡単になります。明らかに、セッションを超えて存続する必要があるアプリケーションの状態がある場合があります (単純なケースではユーザー名とパスワードが必要です) が、セッション状態があるかどうかに関係なく、とにかくこれらのデータを保存する必要があります。

于 2009-04-28T18:20:10.290 に答える
6

通常、同じ Session オブジェクトへの複数のリクエストはキューに入れられるため、Session の使用には注意が必要です。「同時リクエストとセッション状態」を参照してください。http://msdn.microsoft.com/en-us/library/ms178581.aspx。

セッション状態への同時読み取りアクセスを許可するようにEnableSessionState設定できることに注意してください。ReadOnly

このキューイングは、開発者が同期を気にせずに Session を使用できることを意味するため、良いことです。

セッションを「決して」使用しないという同僚の推奨には同意しませんし、自分でロールバックすることも考えません。

于 2009-04-28T20:06:26.853 に答える
6

セッション状態の MS 実装自体は悪いものではありません...一部の開発者はそれを使用しています。前述のように、組み込みのセッション状態プロバイダーを使用すると、セキュリティ、エージング、および同時実行の問題を再発明する必要がなくなります。状態とページの遷移を管理するためのより良い方法を見つけるのが面倒なので、セッションに大量のゴミを詰め込み始めないでください。セッションはあまりうまくスケーリングしません...サイトの各ユーザーがセッションにたくさんのオブジェクトを詰め込み、それらのオブジェクトがアプリで利用できる有限のメモリを少し占有すると、問題がすぐに発生します.後でアプリの人気が高まるにつれて。設計された方法でセッションを使用します。つまり、ユーザーがまだサイトを「使用」していることを表すトークンです。それを超えて挑戦し始めると、

于 2009-04-28T18:21:41.330 に答える
3

これにセキュリティ上の懸念はありますか？

自分でロールする場合は、セッション固定とハイジャック攻撃を処理する必要がありますが、組み込みのセッションを使用すると、それらは処理されると思います (ただし、間違っている可能性があります)。

于 2009-04-28T18:10:44.667 に答える
3

あなたが説明した自家製のセッションは、.Netセッションの異なる「SQL」状態を何もしていません。私の経験では、とにかくセッションがパフォーマンスを低下させるとは思いません。独自のセッション マネージャーを構築するには、他のいくつかの配管タスク (セキュリティ、フラッシュ アウトなど) を追加する必要があります。

組み込みセッションの利点は、このすべての配管がすでに処理されているため、使いやすいことです。「SQL」モードでは、セッション データをデータベースに永続化できるため、問題なく Web ファームでアプリを実行できます。

Fortune 57 の企業向けに、1 日に 10 万件を超えるトランザクションを処理し、セッション [SQL モード] をまったく問題なく広範囲に使用する b2b e コマース アプリを設計しました。

于 2009-04-28T18:14:00.757 に答える
2

私が間違っている場合は私を訂正してください：

セッション状態をデータベース（SQL Serverなど）に保存する主な利点は、メモリリソースを消費せず、代わりにデータベースのディスクに保存することです。

欠点は、必要になるたびにデータベースからこの情報を取得するためにIOヒットを取得することです（または、SQL Severは、最近実行されたクエリに基づいてデータの魔法のキャッシュを実行しますか？）

いずれにせよ、これは、Webサーバーへのトリップごとにデータベースからセッション情報を取得するためのIOの価格であり、大量のトラフィックに遭遇するサイトにとってより安全な戦略のようです。

于 2009-04-28T19:51:31.240 に答える