9

現在、Web サービスに取り組んでおり、返される結果が非常に大きくなる可能性があります (> 5 MB)。

このデータ セットがこれほど大きく、Web サービスが同期または非同期のいずれかであるということは完全に妥当ですが、次のことについて人々の考えがどうなっているのか疑問に思っています。

  1. 接続が失われた場合、結果セット全体を再生成して再度送信する必要があります。接続が失われたりリセットされたりした場合、何らかの「再開」を行う方法はありますか?

  2. これほど大きな結果セットを送信することは適切ですか? 結果セットが生成されてサーバーに保存され、クライアントが結果セットのチャンクを少量ずつダウンロードし、最後にセットを再構築できる、ある種の「ページング」を実装する方がよいでしょうか?

4

4 に答える 4

3

paged、store and retrieve、Massive pushの 3 つのアプローチすべてを見てきました。

問題の解決策は、結果セットが非常に大きい理由とその生成方法にある程度依存すると思います。結果は時間の経過とともに増加しますか?一度にすべて計算されてからプッシュされますか?結果が得られたらすぐにストリーミングして返しますか?

ページングアプローチ

私の経験では、検索結果のページと同様に、クライアントが適切なサイズの結果セットのチャンクにすばやくアクセスする必要がある場合は、ページング アプローチを使用するのが適切です。ここでの考慮事項は、プロトコルの全体的なチャット性、クライアント ページ要求間の結果セット全体のキャッシュ、および/または結果のページを生成するのにかかる処理時間です。

保存と検索

格納と取得は、結果がランダム アクセスではなく、クエリが処理されるにつれて結果セットのサイズが大きくなる場合に役立ちます。ここで考慮すべき問題は、クライアントの複雑さと、ユーザーに部分的な結果を提供できるかどうか、またはクライアントに何かを返す前にすべての結果を計算する必要があるかどうかです (分散検索エンジンからの結果の並べ替えを考えてください)。

大プッシュ

大規模なプッシュ アプローチには、ほぼ確実に欠陥があります。クライアントがすべての情報を必要とし、それをモノリシックな結果セットにプッシュする必要がある場合でも、WS-ReliableMessaging(直接または独自の簡略化されたバージョンを介して) アプローチを取り、結果をチャンク化することをお勧めします。こうすることであなたは

  1. ピースがクライアントに確実に届くようにする
  2. クライアントからレシートを受け取るとすぐにチャンクを破棄できます
  3. サーバー側とクライアント側で5MBのXML、DOM、またはその他のものをメモリに保持する必要があるため、メモリ消費に関する問題を減らすことができます(結果をストリーミング方式で処理していないと仮定します)。

ただし、他の人が言っているように、結果セットのサイズ、その生成方法、および全体的なパフォーマンスが実際の問題であることがわかるまで、何もしないでください。

于 2009-05-28T13:47:30.103 に答える
2

結果セットのサイズとして 5 Mb を禁止する厳しい法律はありません。400 Mb を超えると送信が困難になる場合があります。

非同期ハンドラーを自動的に取得します (.net を使用しているため)

結果セットが生成されてサーバーに保存されるある種の「ページング」を実装すると、クライアントは結果セットのチャンクを少量ずつダウンロードし、最後にセットを再構築できます

それはあなたのためにすでに起こっています-それはtcp/ipと呼ばれています;-)それを再実装するのはやり過ぎかもしれません。

同様に --

結果セット全体を再生成して再度送信する必要があります

たとえば、ほとんどの結果セットを生成しているのが MS-SQL の場合、再生成すると、SQL Server の暗黙的なキャッシュが利用され、後続の生成が高速になります。

使用しているプラ​​ットフォームが多くのパフォーマンスのボトルネックを処理してくれるので、これらの問題が「実際の」問題として表面化するまでは、ある程度は心配する必要はありません。

于 2008-08-15T00:18:19.303 に答える
0

secretGeek のコメントには多少同意しません。

それはあなたのためにすでに起こっています-それはtcp/ipと呼ばれています;-)それを再実装するのはやり過ぎかもしれません。

これだけを行いたい場合もありますが、実際には UI の観点からのみです。データをクライアントにストリーミングする方法を実装する場合 (プッシュレット メカニズムのようなものを介して)、または提案どおりにページにチャンクする場合は、クライアントに非常に小さなサブセットをロードしてから、ゆっくりと UI を構築することができます。データの全量。

これにより、(ユーザーの観点から) より滑らかで高速な UI が実現しますが、余分な労力が価値があるかどうかを評価する必要があります.

于 2008-08-15T00:31:36.360 に答える
0

したがって、「開始レコード番号」と「最終レコード番号」パラメーターを Web メソッドに追加するソリューションに興味があるようです。(または「ページ番号」および「ページあたりの結果」)

行番号付けのサポートが組み込まれているため、バッキング ストアが SQL サーバー (または mysql) である場合、これはそれほど難しくありません。

それにもかかわらず、サーバーでのセッション管理を回避し、結果セットの明示的なキャッシュを回避し、バッキング ストアのキャッシュに頼って生活をシンプルに保つことができるはずです。

于 2008-08-15T01:40:05.410 に答える