22

まず、現在の環境について簡単に説明します。多くの ASP.NET アプリケーションがあり、そのすべてが特定の側面でセッションを使用しています。トラフィック レベルのために複数のサーバーで「負荷分散」されていますが、現在すべての Web アプリケーションがセッション状態に「InProc」を使用するように設定されているため、負荷分散は「スティッキー セッション」を使用するように設定されています。

トラフィック負荷が原因でサーバーが過負荷になる可能性があるため、ロードバランサーの「スティッキーセッション」構成を削除できるようにすることを検討しています。よりバランスの取れたアプローチを採用したいのですが、セッションを使用できる必要があります。

セッション状態の SqlServer が機能することはわかっていますが、制御できない理由により、SqlServer を使用して状態を保存することはできません。調査では、StateServer が最善の策のようです。追加のサーバーがあり、大量のメモリが配置されています。このサーバーは、Web クラスター全体の StateServer になる可能性があります。以下のことを知りたいだけです。

1.) InProc から StateServer への切り替えに関するシリアライゼーションの問題の可能性以外に、上記の環境でセッション オブジェクトが失われたり、エラーが生成されたりするという既知の問題はありますか?

2.) 単一障害点とわずかに遅いパフォーマンス以外に、StateServer を使用する際に注意する必要があるその他の問題があります。

3.) 3 種類の状態ストレージのパフォーマンスの違いを示す指標はありますか?

4

6 に答える 6

3

私はSQLとインプロセスのみを使用しました。ただし、SQL Server を使用する場合に適用されるこれら 3 つは同様に適用されます。

  • シリアル化とネットワーク経由で送信されるデータの両方に影響するため、セッションに多くの情報を保存しないでください。
  • Session_onEnd に依存するものがないことを確認してください。これは、アウト プロセス セッションでは使用できません。
  • セッションを使用しないページでセッションをオフにします。これは、インプロセス セッションでは違いがありませんが、アウト プロセスでは大幅に節約できます。
于 2009-03-26T19:56:21.427 に答える
2

サーバーの etag ID が Web ファーム全体で同期されていることを確認してください。そうしないと、クライアント ブラウザーでのキャッシュが混乱します。

コードを詳細に見直して、すべてをプロセス外で LAN 経由で効率的にシリアル化できることを確認しましたか?

システム内の主要なパフォーマンスの問題を解決していますか? データベースが競合の典型的な原因であるため、お尋ねします。

スティッキー セッションから離れる主な動機は、問題のあるサーバーのサイクル ダウンやソフトウェア アップグレードの展開など、運用上の柔軟性でした。そのため、中央のセッション状態サービスを実装したら、運用上の観点から最大限に活用してください。

于 2009-03-26T19:57:06.090 に答える
0

受け入れられた答えにもう1つ指摘したいと思います：

  • フレームワーク dll のバージョンが同じであることを確認してください。

私の場合、ファームのサーバーの 1 つでいくつかの Windows 更新がスキップされたため、System.Web dll のバージョンが異なっていました。

于 2013-04-09T08:46:37.827 に答える