压缩XML指标。
我有一个客户端服务器应用程序，它通过TCP / IP从客户端发送XML到服务器，然后广播到其他客户端。 我如何知道通过压缩XML而不是通过常规流发送来保证性能改进的XML的最小尺寸。
对此或示例有什么好的指标吗？
Xml通常压缩得很好，因为它往往会有很多重复。
另一种选择是交换为二进制格式; BinaryFormatter或NetDataContractSerializer是简单的选项，但与xml相比，两者都是非常不兼容的（例如与java）。
另一种选择是便携式二进制格式，例如谷歌的“协议缓冲区”。 我维护一个名为protobuf-net的.NET / C＃版本。 它被设计为与常规.NET方法（例如XmlSerializer / DataContractSerializer）并排兼容，但是比xml小得多，并且对序列化和反序列化的处理（CPU等）要少得多。
此页面显示了XmlSerializer，DataContractSerializer和protobuf-net的一些数字; 我认为它包括有/无压缩的统计数据，但它们似乎已经消失了……
[更新]我应该说 – QuickStart项目中有一个TCP / IP示例。
一个松散的指标是压缩任何大于单个数据包的东西，但这只是挑剔。
没有理由不在应用程序内部使用二进制格式 – 无论压缩需要多长时间，网络开销将比压缩慢几个数量级（除非我们谈论非常慢的设备）。
如果这两个建议不能让您放心，您可以随时进行基准测试以找到要压缩的位置。
一定要压缩它。
它可以为超过2个标签的任何东西节省带宽。
要确定压缩是否对您有任何益处，您需要使用预期将流经系统的实际或预期数量的数据来运行一些测试。
希望这可以帮助。
在我们所做的测试中，我们发现了一个巨大的好处，但要注意CPU的含义。
在我工作的一个项目中，我们向运行.NET的客户端发送了大量XML数据（> 10 meg）。 （我不是建议这样做的方式，这只是我们发现自己的情况!!）我们发现，随着XML文件变得足够大，Microsoft XML库无法解析XML文件（机器用完了）记忆，甚至在机器上> 1演出）。 更改XML解析库最终有所帮助，但在我们这样做之前，我们对我们传输的数据启用了GZIP压缩，这有助于我们解析大型文档。 在我们的两个基于Linux的websphere服务器上，我们能够生成XML，然后相当容易地对它进行gzip。 我认为有50个用户同时执行此操作（加载大约10到20个这些文件），我们能够做到这一点，大约50％的CPU。 XML的压缩似乎在服务器上比在.net gui上更好地处理（即解析/ cpu时间），但这可能是由于上面使用的Microsoft XML库的不足之处。 正如我所提到的，有更好的库可用更快并且使用更少的内存。
在我们的例子中，我们的大小也有了很大的改进 – 我们在某些情况下将50兆的XML文件压缩到大约10兆。 这显然也有助于网络性能。
既然我们担心影响，以及这是否会产生其他后果（我们的用户似乎在大浪中做事情，所以我们担心我们的CPU耗尽）我们有一个配置变量，我们可以使用它来转gzip开关。 我建议你这样做。
另一件事：我们还将XML文件压缩，然后将它们保存在数据库中，这节省了大约50％的空间（XML文件范围从几K到几兆，但大多数都相当小）。 除了选择特定级别以区分何时使用压缩之外，执行所有操作可能更容易。