0

うまくいけば、これはあまりにもオープンエンドではありません。私は.NET 4, WPF, WCF, EF (STE's), SQL 2012アプリケーションに取り組んでいます。

利用可能な帯域幅があまりない場合、アプリケーションがタイムアウトし、低速のネットワークでハングするため、顧客から打撃を受けています。

このアプリケーションには、「リアルタイム」のダッシュボードのようなディスプレイと、グリッドベースのデータ エディター画面がいくつかあります。

Fiddler を使用して、製品内のさまざまな機能領域を詳しく調べました。特に、転送されるデータの量に焦点を当てました。つまり、転送されるデータが多すぎます。一部の WCF 呼び出しは、1 回の呼び出しで 100 MB を超えるデータを取得します。

私たちが目にしている問題は、WCF と EF を介してデータを取得するときに十分な注意が払われていないという事実によって特徴付けられると思いますが、おそらく私は物事を分析しすぎています。

  • 私は再利用性の大ファンですが、必要なのは選択リストの ID と名前だけなのに、完全に水和された EF STE エンティティを返す必要があるのはなぜですか? 場合によっては、単純な読み取り専用のデータ表示が必要になることがあります。OriginalValues コレクションなどを含む ChangeTracker 情報をシリアライズするのはなぜですか? おそらく、エンティティを編集可能な「読み取り専用バージョン」に分割するか、適切なバージョンを選択する価値がありますか?

  • 現在、BasicHttpBinding/XML Serialization を使用していますが、ペイロードが肥大化しているようです。たとえば、xml には名前空間とその他のノイズが含まれています。IIS 7 圧縮を有効にすることで大幅に改善されましたが、他にできることはありますか? JSON 形式は、データの転送に適していますか? ただし、XML を JSON に変更することは大きな変更のように思えます。

  • ペイロード サイズを軽減するために使用できる他の手法はありますか。おそらく、XML シリアライゼーションに固執することはできますが、要求するデータを減らす必要があるだけです。おそらく、ページングや「無限スクロール」、遅延バックグラウンド読み込みなどの手法を使用することをお勧めします。

容認できないほど大きなペイロード サイズに直面した人はいますか? それを解決するために何をしましたか？

ありがとう！

4

1 に答える 1

1

私はあなたが大きなものをカバーしたと思います。

可能な限り、完全なエンティティではなく DTO を使用します (必要なデータのみを含む単純なデータ型)。必要なのは単純な変換クラスだけです。コード生成ツールや AutoMapper などを使用して、ここで作業することもできます。

BasicHttpBinding の代わりに NetTcpBinding を使用します。これにより、メッセージ サイズが大幅に縮小されますが、HTTP/Fiddler のデバッグが失われ、IIS 構成が必要になります。

または、HTTP に固執し、XML の代わりに JSON を使用する場合は、SOAP であるため、WCF BasicHttpBinding では簡単に実行できませんが、ギアをシフトして代わりに WebAPI を試すことができます。ただし、これはクライアントとサーバーの両方にとって重要な変更になります。

それらはあなたのサイズをかなり小さくするはずです. そこから、データをチャンクで取り込むか、1 つの大きなクエリの代わりに多数の個別のクエリを使用するかを検討し続けます。それらによって全体的な帯域幅が減少しない場合でも、より優れたユーザー エクスペリエンスが提供されます。

于 2013-05-28T18:45:53.680 に答える