压缩XML指标。

Question

我有一个客户端服务器应用程序，它通过TCP/IP从客户端向服务器发送XML，然后向其他客户端广播。我如何知道通过压缩XML而不是通过常规流发送的最小尺寸的XML可以保证性能的提高。

这个或者例子有什么好的指标吗？

Answer 1

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

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

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

This page显示了XmlSerializer，DataContractSerializer和protobuf-net的一些数字;我想到它包括统计数据/无压缩，但他们似乎已经消失...

[更新]我应该说 - 在QuickStart项目中有一个TCP/IP示例。

Answer 2

通过一切手段总是压缩它。

它将为您带宽超过2个标签的任何东西。

Answer 3

要确定压缩对您是否有任何好处，您需要运行一些使用实际或预期数据类型的测试，这些数据可能会流过您的系统。

希望这会有所帮助。

Answer 4

一个松散的度量标准将压缩大于单个数据包的任何东西，但这只是挑剔。

没有理由在应用程序内部不要使用二进制格式 - 无论需要多长时间压缩，网络开销将比压缩慢几个数量级（除非我们谈论的速度很慢设备）。

如果这两个建议不让你放心，你可以随时找到要压缩的点。

Answer 5

在我们所做的测试中，我们发现了巨大的好处，但请注意CPU的含义。

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

在我们的例子中，我们也得到了巨大的改进 - 我们在某些情况下将50兆的XML文件压缩到了大约10兆。这显然也有助于网络性能。由于我们担心这种影响，以及这是否会产生其他后果（我们的用户似乎在大浪中做事，所以我们担心我们会用完CPU），我们有一个配置变量，我们可以用来打开/关闭gzip。我建议你也这样做。另一件事：我们在将XML文件保存到数据库中之前，还压缩了XML文件，这节省了大约50％的空间（XML文件从几K到几兆，但大部分都很小）。做任何事都可能比选择特定级别来区分何时使用压缩更容易。