を使用してエンドポイントをWCF公開する Windows Server 2008/IIS でホストされているサービスがあります。このサービスは、さまざまなパフォーマンスの問題に悩まされている Windows フォーム アプリケーションによって使用されます。企業ネットワークを介してサーバーからクライアントに転送されるペイロードを削減するために、(バージョン r580) シリアル化エンジンを属性を使用してサービスの操作の一部に統合することにしました。nettcpbindingDataContractSerializerprotobuf-netProtoBehavior
を統合する前protobuff-netは、シリアライズされたサーバ レスポンスの累積サイズは約 18 MB でした。その後、クライアントとサーバーの両方の WCF トレース ログで確認したところ、1.6 MB でした。残念ながら、これによってクライアント アプリケーションの読み込み時間が短縮されることはありませんでした。
さらに詳しく調べたところ、ネットワーク トラフィック ツールで報告されたように、クライアントがネットワーク経由で受信したバイト数は、前後で約protobuf1MBprotobufしか違わないことがわかりました。どうすればいいの？シリアル化された形式 (いくつかのメッセージで構成される) でほぼ 15 MB 異なるペイロードが、ネットワーク経由で送信されたときに 1 MB の違いしか表せないのはなぜですか? protobuff基になるストリームが特定の方法で組み立てられている場合、結果の TCP ストリームが過度に肥大化する可能性はありますか?
さらに、protobuf-netシリアル化された 1.6 MB のペイロードは複数の応答メッセージで構成されており、そのうちの 1 つは約 1.25 MB です。これが問題になる可能性がありますか？それをより小さな応答に分割する必要がありますか? もしそうなら、閾値は何ですか？
数週間私を困惑させてきたので、これに関する意見をいただければ幸いです。に関連する投稿を何時間も費やしてきましたがprotobuf-net、コンパクトなシリアル化形式を提供するという約束を果たしていますが、実際にはその利点を実感できていません。
前もって感謝します。