1

これは、App_Code フォルダーにコードがあり、ハードウェア ロード バランサーを使用しているすべての人にとっての質問です。ハードウェア ロード バランサーをスティッキー セッションに設定して問題を解決できるのは事実ですが、完璧な世界では、機能をオフにしたいと思います。

App_Code フォルダー内のファイルで、サイトがプリコンパイルされていない場合、iis はこれらのファイルに対してランダムなファイル名を生成します。

server1 "/ajax/SomeControl, App_Code.tjazq3hb.ashx"
server2 "/ajax/SomeControl, App_Code.wzp3akyu.ashx"

そのため、ユーザーがページを投稿して他のサーバーに転送されても、何も機能しません。

誰かがこれに対する解決策を持っていますか? 事前にコンパイルされた Web サイトに変更することはできますが、QA 部門が変更されたファイルを宣伝するだけでは不十分です。

4

8 に答える 8

2

両方のサーバーの<machinekey>ノードを同じ値に設定していますか？

これを設定するには、web.configのmachine.configファイルをオーバーライドできます。これは一致する必要があります。一致しないと、このような奇妙な状況が発生する可能性があります。

于 2008-09-08T22:16:08.770 に答える
1

ロードバランサーはスティッキーセッションをサポートしていますか？これをオンにすると、バランサーは特定の時間枠内に同じIPを同じサーバーに何度もルーティングします。このように、1つのクライアントからのすべてのリクエスト（AJAXまたはその他）は、常にクラスター/ファーム内の同じサーバーにヒットします。

于 2008-09-08T21:49:23.543 に答える
1

わかりました、まず最初に... MachineKey は true です。これは、負荷分散されたすべてのマシンで絶対に同じに設定する必要があります。それが影響するすべてを覚えているわけではありませんが、とにかく実行してください。

次に、サイトをプリコンパイルします。ページが再コンパイルされるページの .cs ファイルがあるときはいつでも、実際には新しいバージョンをプッシュすることができます。注意が必要なのは、単一の dll にコンパイルされる app_code ファイルです。ただし、そこに変更が加えられた場合は、新しい dll をアップロードすることができ、再びすべてがうまくいくはずです。

さらに簡単にするには、[固定の名前と単一ページのアセンブリを使用する] オプションを有効にします。これにより、コンパイルごとに同じ名前が付けられるため、変更された .dll ファイルをテストしてから置き換えるだけです。

とはいえ、そのまま問題を抱えているべきではありません。要求は IIS に送られ、IIS はページを提供し、必要に応じてコンパイルします。背後にあるコードが各マシンで異なっていても、実際には問題にはなりません。コードは同じであり、そのマシンは独自のコードを参照します。実際のリクエスト/ポストバックは、それを知らないか、気にしません。上記で述べたことはすべて物事を単純化するのに役立つはずですが、とにかく機能するはずです...したがって、おそらくマシンキーの問題です.

于 2009-07-15T18:59:34.603 に答える
0

はViewState暗号化専用のようです。自動コンパイルされたアセンブリのファイル名には影響しません。

于 2008-09-09T00:11:15.903 に答える
0

ハードウェアロードバランサーの場合は、問題は発生しないはずです。サーバーがリクエストされたページをコンパイルして提供するリクエストURLがわかっているからです。

私が考えることができる唯一の問題は、セッションとビューの状態です。

于 2008-09-08T21:49:53.870 に答える
0

確かに、ハードウェアロードバランサーをスティッキーセッションに設定して問題を解決することもできますが、完璧な世界では、この機能をオフにしたいと思います。

于 2008-09-08T21:57:59.640 に答える
0

QA 部門がそのライブラリ全体を昇格できる場合は、app_code にあるものを外部クラス ライブラリに移動できます。事前にコンパイルされたサイトに切り替えるための便利な方法または許容できる方法が見つからない場合は、スティッキー セッションに悩まされていると思います。

于 2008-09-09T05:53:57.203 に答える
0

asp.net モデルは暗号化とマシン固有のストレージにかなり依存していると思うので、セッションのスティッキー IP を回避するために機能するかどうかはわかりません。

ASP.NET AJAX については知りませんが (代わりに MonoRail NJS アプローチを使用します)、セッション状態が問題になる可能性があります。

セッション状態がシリアライズ可能であることを確認する必要があり、InMemory セッションを使用しないでください。おそらく、ASP.NET セッション状態サーバーを実行して、フロントエンド ファーム全体が同じセッション ストレージを使用していることを確認する必要があります。そのような場合、セッションは完全にシリアライズ可能でなければなりません (そのため、セッション内のオブジェクトが優先されず、常に ID を使用する必要があり、MS が AJAX ライブラリ開発を行うときにこの制限に固執するに違いありません)

于 2008-10-10T09:09:23.503 に答える