压缩 XML 指标 .

Xml 通常压缩得很好，因为它往往有很多重复。

另一种选择是交换为二进制格式;BinaryFormatter或NetDataContractSerializer是简单的选项，但与xml相比，两者都是不兼容的（例如与java）。

另一种选择是可移植的二进制格式，例如谷歌的"协议缓冲区"。我维护一个.NET/C#版本，称为protobuf-net。它被设计为与常规 .NET 方法（如 XmlSerializer/DataContractSerializer）并行兼容，但比 xml 小得多，并且序列化和反序列化所需的处理（CPU 等）要少得多。

此页面显示了 XmlSerializer、DataContractSerializer 和 protobuf-net 的一些数字;我以为它包括有/没有压缩的统计数据，但它们似乎已经消失了......

[更新] 我应该说 - 快速入门项目中有一个 TCP/IP 示例。

一个松散的指标是压缩比单个数据包更大的任何内容，但这只是吹毛求疵。

没有理由避免在应用程序内部使用二进制格式 - 无论压缩需要多少时间，网络开销都会比压缩慢几个数量级（除非我们谈论的是非常慢的设备）。

如果这两个建议不能让您放心，您可以随时进行基准测试以找到要压缩的位置。

一定要始终压缩它。

它将为您节省超过 2 个标签的带宽。

要确定压缩是否对您有任何好处，您需要使用实际或预期数量的预期数据流经系统来运行一些测试。

希望这有帮助。

在我们所做的测试中，我们发现了一个巨大的好处，但是要注意CPU的影响。

在我参与的一个项目中，我们将大量 XML 数据（> 10 meg）发送给运行 .NET 的客户端。（我不建议这样做作为一种做事方式，这只是我们发现自己所处的情况！！我们发现，当 XML 文件变得足够大时，Microsoft XML 库无法解析 XML 文件（即使在 1 GB>机器上，机器的内存不足）。更改 XML 解析库最终有所帮助，但在此之前，我们对传输的数据启用了 GZIP 压缩，这有助于我们解析大型文档。在我们两个基于 linux 的 websphere 服务器上，我们能够生成 XML，然后相当容易地对其进行 gzip 压缩。我认为有 50 个用户同时执行此操作（加载大约 10 到 20 个这些文件），我们能够用大约 50% 的 CPU 做到这一点。XML的压缩似乎在服务器上比在.net GUI上处理得更好（即解析/cpu时间），但这可能是由于所使用的Microsoft XML库的上述不足。正如我所提到的，有更好的库可用，它们更快，使用更少的内存。

在我们的案例中，我们在大小上也得到了巨大的改进——在某些情况下，我们将 50 meg XML 文件压缩到大约 10 meg。这显然也有助于提高网络性能。

由于我们担心

影响，以及这是否会产生其他后果（我们的用户似乎在浪中做事，所以我们担心我们会耗尽 CPU），我们有一个配置变量，我们可以用来打开/关闭 gzip。我建议你也这样做。

另一件事：在将XML文件持久化到数据库中之前，我们还压缩了它们，这节省了大约50%的空间（XML文件的范围从几K到几兆，但大部分都相当小）。做所有事情可能比选择特定级别来区分何时使用压缩更容易。