圧縮XMLメトリック。

Question

クライアントからサーバーにTCP / IP経由でXMLを送信し、他のクライアントにブロードキャストするクライアントサーバーアプリケーションがあります。通常のストリームで送信するのではなく、XMLを圧縮することでパフォーマンスの改善を保証するXMLの最小サイズを知るにはどうすればよいですか。

これまたは例について良い指標はありますか

Answer 1

Xmlは、繰り返しが多い傾向があるため、通常非常に圧縮されます。

別のオプションは、バイナリ形式にスワップすることです。 BinaryFormatterまたはNetDataContractSerializerは単純なオプションですが、両方ともxmlと比較して、（たとえばjavaと）互換性がないことで有名です。

別のオプションは、Googleの「プロトコルバッファ」などのポータブルバイナリフォーマットです。 protobuf-net という.NET / C＃バージョンを維持しています。これは、通常の.NETアプローチ（XmlSerializer / DataContractSerializerなど）と共存できるように設計されていますが、xmlよりもはるかに小さく、シリアル化と逆シリアル化の両方で必要な処理（CPUなど）が大幅に少なくなります。

このページには、XmlSerializer、DataContractSerializer、およびprotobufの数値が表示されます。 -ネット;圧縮の有無に関係なく統計が含まれていると考えましたが、消えてしまったようです...

[更新]言っておくべきでした-QuickStartプロジェクトにはTCP / IPの例があります。

Answer 2

大まかなメトリックは、単一のパケットよりも大きいものを圧縮することですが、それはただのピッキングです。

アプリケーションで内部的にバイナリ形式を使用することを控える理由はありません-圧縮にどれだけ時間がかかっても、ネットワークのオーバーヘッドは圧縮よりも数桁遅くなります（非常に遅いデバイスについて話していない限り） ）。

これらの2つの提案で安心できない場合は、いつでもベンチマークを行って、圧縮する場所を見つけることができます。

Answer 3

必ず、常に圧縮する。

2つ以上のタグがあれば、帯域幅を節約できます。

Answer 4

圧縮にメリットがあるかどうかを判断するには、システムを流れると予想される種類のデータの実際または予想される量を使用して、いくつかのテストを実行する必要があります。

これがお役に立てば幸いです。

Answer 5

私たちが行ったテストでは、大きな利点が見つかりましたが、CPUの影響に注意してください。

私が取り組んだプロジェクトでは、大量のXMLデータ（＆gt; 10メガグラム）を.NETを実行しているクライアントに送信していました。 （私はこれを物事の方法として推奨していません、それは私たちが見つけた状況です！）XMLファイルが十分に大きくなると、Microsoft XMLライブラリはXMLファイルを解析できませんでした（マシンが使い果たされました）マシンであっても＆gt; 1ギガバイト）。 XML解析ライブラリの変更は最終的には役立ちましたが、その前に、転送したデータのGZIP圧縮を有効にして、大きなドキュメントの解析に役立てました。 2つのLinuxベースのWebsphereサーバーで、XMLを生成し、それをかなり簡単にgzipできました。 50人のユーザーがこれを同時に実行すると（これらのファイルを約10から20個ロードする）、約50％のCPUでこれを実行できたと思います。 XMLの圧縮は、.net guiよりもサーバーでより適切に処理されているようです（つまり、解析/ CPU時間）が、これはおそらく、使用されているMicrosoft XMLライブラリの上記の不備によるものです。前述したように、より高速でメモリ使用量の少ない優れたライブラリが利用可能です。

私たちの場合、サイズも大幅に改善されました。場合によっては、50メガのXMLファイルを約10メガに圧縮していました。これは明らかにネットワークのパフォーマンスにも役立ちました。

影響について心配していたので、これが他の結果をもたらすかどうか（ユーザーは大きな波で何かをしているようだったので、CPUを使い果たすのではないかと心配していました）使用できるconfig変数がありましたgzipのオン/オフを切り替えます。これも行うことをお勧めします。

別のこと：XMLファイルをデータベースに永続化する前に圧縮し、これにより約50％のスペースを節約しました（XMLファイルは数Kから数MBですが、ほとんどがかなり小さい）。圧縮を使用するかどうかを区別するために特定のレベルを選択するよりも、おそらくすべてを行う方が簡単です。