10

ちょっとした裏話: 私は、編集/操作のためにユーザーにデータを渡す前に、データを準備/クランチするのにかなりの時間を必要とする Web アプリケーションに取り組んでいます。データ要求タスクは、完了に 15/20 秒、処理に数秒かかります。そこに到達すると、ユーザーはその場で値を操作できます。値を操作するには、データを完全に再処理する必要があります。

更新: 混乱を避けるために、データ呼び出しを 1 回だけ行い (15 秒のヒット)、結果をメモリに保持して、ユーザーが 100% 作業を完了するまで再度呼び出す必要がないようにしたいと考えています。 . そのため、最初のプルには時間がかかりますが、Ajax を使用して、メモリ内のデータをヒットして常に更新し、応答時間を約 2 秒程度に保ちます (希望)。

これを効率的にするために、初期データをメモリに移動し、サーバーへの Ajax コールバックを使用して、このユーザーの更新で発生する再計算を処理するための処理時間を短縮できるようにしています。

これが私の質問です。パフォーマンスを念頭に置いて、このデータを保存する最良の方法は何ですか。特定の瞬間にこのデータを使用して作業するユーザーは 1 人だけであると仮定します。

また、ユーザーはこのプロセスで数時間作業している可能性があります。ユーザーがデータを操作しているときに、セッションが何らかの方法で中断された場合に、ユーザーの現在のデータを (データベースまたはシリアル化されたバイナリ ファイルに) 保存するために、何らかのフェイルセーフが必要になります。言い換えれば、ユーザーが長時間接続を切断したり気が散ったりした場合に備えて、メモリ オブジェクトのデータをダンプできる適切なフックを備えたソリューションが必要になります。

これまでのところ、ここに私の考えがあります：

セッション状態 - 長所: 1 人のユーザーにロックされます。私のフェイルセーフ要件を満たすセッション終了イベントがあります。短所：現在のオプションの中で最も遅いパフォーマンス。セッション終了イベントは、適切に発生することを確認するのが難しい場合があります。

キャッシュ - 長所: 優れたパフォーマンス。後でボーナスになる可能性がある依存関係にアクセスできますが、現在の範囲ではあまり役に立ちません。短所: 時間間隔に基づく書き込み以外に、簡単なフェールセーフ手順はありません。グローバルな範囲 - ユーザーがお互いの作業と衝突しないようにする必要があります。

静的 - 長所: 最高のパフォーマンス。現在のクラス構造を直接活用できるため、保守が容易です。短所: 時間間隔に基づく書き込み以外に、簡単なフェールセーフ手順はありません。グローバルな範囲 - ユーザーがお互いの作業と衝突しないようにする必要があります。

私が選択すべきオプションについて、誰か提案/コメントはありますか?

ありがとう！

更新: 言い忘れましたが、私はこのタスクを実行するために VB.Net、Asp.Net、および Sql Server 2005 を使用しています。

4

6 に答える 6

0

最初の結果をユーザーに送信するときに、新しいデータベース テーブル (EDIT と呼びましょう) にデータのコピーを作成することをお勧めします。パフォーマンスが問題になる場合は、バックグラウンド スレッドでこれを行います。

ユーザーがデータを編集するときに、テーブルを更新します (パフォーマンスが問題になる場合は、バックグラウンド スレッドでも)。スレッドを使用する必要がある場合は、行の更新を開始する前に、最初のスレッドが終了していることを確認する必要があります。

これにより、ユーザーは離れて戻ってきたり、ブラウザを再起動して、結果に満足したと感じたらいつでもコミットすることができます。

于 2009-02-09T16:34:00.090 に答える
0

他の人が言及したことの1つの可能な代替案は、データをクライアントに保存することです。データセットが大きすぎず、それを操作するコードをクライアント側で処理できると仮定します。データを XML データ アイランドまたは JSON オブジェクトとして格納できます。このデータは、サーバーへのラウンドトリップなしで、すべてのクライアント側で操作/処理および処理できます。このデータをサーバーに保持する必要がある場合は、最終結果のデータを AJAX または標準のポストバック経由でポストできます。

これがあなたの要件でうまくいかない場合は、他のコメントが示唆しているように、SQLサーバーに保存するだけです。

于 2009-02-12T00:23:03.137 に答える
0

ページの読み込み時にデータを保存するためのキャッシュ方法を使用します。競合を避けるために、データを保存するキャッシュに名前を付けることができます。

ユーザーが行った変更を追跡するには、より古い方法を使用します。ユーザーが変更を加えるたびにテキスト ファイルに追加し、そのファイルを定期的にスイープして変更を DB に保存します。ユーザー/アカウントまたはその他のセッション固有のインジケーターに基づいてファイルに名前を付ける場合、競合の問題はなく、アプリ (または他のサポートアプリ、一般的にはより良いアイデアである可能性があります) は、そのようなすべてのファイルを一掃し、セッションが終了しても DB を更新します。

これの最初の部分は、より多くの書き込みをずらすように調整できます。変更をセッションに保存し、それを間隔を置いてファイルに書き込み、その後、より大きな間隔でファイルをスイープします。パフォーマンスに合わせて調整し、可能なユーザー変更の損失のレベルを選択できます。

于 2009-02-11T22:04:46.573 に答える
0

セッションを使用しますが、それに依存しないでください。

単純に、ユーザーにデータセットに「名前を付ける」ようにし、自動的に、または「保存」ボタンのような単純なものを使用して、ユーザーのために積極的に永続化するようにします。

セッションは (通常) ユーザーのブラウザー インスタンスに関連付けられているため、セッションに依存することはできません。誤ってブラウザーを閉じてしまうと (X ボタンをクリックする、PC がクラッシュするなど)、すべての作業が失われます。これは厄介なことです。

ユーザーがデータの「永続的な」状態をそのように制御できるようになると、セッションを利用してデータをメモリに保持し、それをキャッシュとして活用できます。

于 2009-01-30T18:34:34.280 に答える
0

長所/短所で質問にほとんど答えたと思います。しかし、ピア検証を探しているのであれば、私の投票はセッションです。パフォーマンスは遅くなりますが (どのくらい遅くなるか知っていますか?)、処理には時間がかかります。ユーザーは 15 秒と 17 秒の違いを理解できると思いますか? どちらも Web 用語では「永遠に」なので、実装が最も簡単だと思われる方を使用してください。

おそらく少し話題から外れています。これらの長い処理呼び出しを非同期 (AJAX の非同期と混同しないでください) ページに配置することをお勧めします。

この記事を見て、意味が分からない場合は私に連絡してください。

http://msdn.microsoft.com/en-us/magazine/cc163725.aspx

于 2009-01-30T18:34:58.320 に答える