3

セッション状態を管理するために 150 個のクライアント変数を使用する従来の ColdFusion アプリケーションがあります。クライアント変数は、ラウンド ロビン ロード バランサーを使用して、6 つのアプリケーション サーバー クラスター環境内の SQL Server データベースに集中的に格納されます。

問題は、コードがクライアント変数を新しい値で更新するときに、CData テーブルで新しい値が適切に更新されているにもかかわらず、古い値がまだ使用され、表示されていることです。これは、cfset タグを使用してクライアント変数に対して平均 1000 回の更新が行われる場合に断続的に発生します。

競合状態とキャッシングの問題が考えられる説明です。古い値がまだ 6 つのアプリケーション サーバーの 1 つにキャッシュされているのではないかと「疑っています」。Adobe のドキュメントには、クライアント変数がメモリにキャッシュされることが明確に記載されていますが、詳細については触れられていません。

1) 誰かがこの問題を経験し、適切な解決策を見つけましたか?

2) クライアント変数を使用し続けている間にスティッキー セッションに移行すると、どのような影響がありますか?

4

2 に答える 2

0

参考になる回答ありがとうございます！

アプリケーション サーバーの 1 つがまだクライアント変数の更新を処理しようとしている一方で、次のアプリケーション サーバーが「次の」要求を既に受信しており、更新された値の代わりにキャッシュされた値を使用している可能性があります。これは、アプリケーション サーバーの負荷の問題を示しています。150 個のクライアント変数のシリアライズとデシリアライズが要因である可能性があります。ただし、ご指摘のとおり、アプリケーション サーバーが正常に動作している場合でも、特定の条件下では、データベースのコミットが予想よりも大幅に遅れる (または応答が大幅に遅くなる) 可能性があります。クライアント変数は独自のデータベースに保存されますが、メイン データベースと同じデータベース サーバー上にあります。

変更されたすべてのクライアント変数が、リクエストの最後にデータベースに「フラッシュ」されることに言及するのは興味深いことです。しかし、明確にするために、それらはメモリから (およびデータベースに) フラッシュされ、すべてのアプリケーション サーバーで同時にフラッシュされますか? これにより、他のサーバーにキャッシュされた古い値が削除されるため、サーバーは更新された値をデータベースから取得する必要があります。あるいは、データベースがコミットされると、ColdFusion は残りのアプリケーション サーバーのクライアント変数を更新します。キャッシュされた値が既にメモリに存在するかどうかは関係ありません。

グローバル変数の更新は、パフォーマンス上の理由から、すべての 6 (CF9) 運用サーバーで無効になっています。3 台の (CF9) サーバーがあるテスト サイトでこれを有効にしましたが、断続的な発生は依然として発生しており、はるかに高いレートでさえあります。

さらに....

CFApplication タグの setDomainCookies 属性は「no」です。この設定は、レガシー アプリケーションが 10 年以上前に作成されて以来、常に同じです。ただし、アドビのドキュメントには、クラスター環境には「はい」が必要であることが示されています。Cookie.CFID と Cookie.CFTOKEN の値がアプリケーション サーバー間でどのように共有されるかをさらに分析するための簡単なテスト ページを作成し、テスト ページを使用してキャッシュの問題をさらに調査しています。

于 2013-09-07T11:36:34.077 に答える