我有一个客户端服务器应用程序，它通过TCP/IP从客户端发送XML到服务器，然后广播到其他客户端。如何确定XML的最小大小，以便在压缩XML而不是通过常规流发送时获得性能提升。
是否有任何好的度量标准或示例？
5个回答
2
XML通常可以很好地压缩，因为它往往有很多重复的内容。
另一个选择是切换到二进制格式；BinaryFormatter或NetDataContractSerializer是简单的选项，但与xml相比，两者都出了名的不兼容（例如与java）。
另一个选择是使用可移植的二进制格式，例如谷歌的“协议缓冲区”。我维护着这个称为protobuf-net的.NET / C#版本。它旨在与常规的.NET方法（如XmlSerializer / DataContractSerializer）兼容，但比xml小得多，并且需要更少的处理（CPU等）进行序列化和反序列化。
此页面显示了XmlSerializer、DataContractSerializer和protobuf-net的一些数字；我认为它包括有/无压缩的统计数据，但似乎已经消失了...
[更新] 我应该说 - 在QuickStart项目中有一个TCP/IP示例。
- Marc Gravell
1
一个宽松的度量标准是压缩任何大于单个数据包的内容，但这只是挑剔。
在应用程序内部使用二进制格式没有理由不可行 - 无论压缩需要多少时间，网络开销都比压缩慢几个数量级（除非我们谈论的是非常慢的设备）。
如果这两个建议不能让您放心，您可以随时进行基准测试以找到适合压缩的位置。
- Omer van Kloeten
0
无论如何都要进行压缩。
对于任何具有超过2个标签的内容，这将为您节省带宽。
- Marko
4
但是压缩和解压缩不会增加额外的开销吗？ - leora
你还应该考虑客户端如何解释XML，例如对于大型XML，使用SAX解析压缩流与必须通过DOM解压缩和加载整个XML之间的区别。 - John Lemp
你可以随时在流上使用一些即时压缩/解压缩。我不知道C#是否适用，但在Java中效果很好：
InputStream st = new GZipInputStream(inStream);
st.read() - Marko
@Marko - 这将几乎完全相同：new GZipStream(inStream, CompressionMode.Decompress)。 - Marc Gravell
0
要决定压缩是否对您有益，您需要运行一些测试，使用实际或预期的数据量，以确定将流经您的系统的数据类型。
希望这可以帮助到您。
- norbertB
0
在我们进行的测试中，我们发现了巨大的好处，但是请注意CPU方面的影响。
我曾经参与的一个项目中，我们向运行.NET的客户端发送大量的XML数据（>10兆）。 （我不建议这样做，这只是我们发现自己处于的情况！）我们发现随着XML文件足够大，Microsoft XML库无法解析XML文件（即使在大于1吉字节的机器上，机器也会用完内存）。最终更改XML解析库有所帮助，但在此之前，我们启用了数据传输上的GZIP压缩，这有助于我们解析大型文档。在我们的两个基于Linux的WebSphere服务器上，我们能够相当容易地生成XML并对其进行gzip压缩。我认为，在同时执行此操作的50个用户（加载约10到20个这些文件）时，我们能够正常完成此操作，并且占用约50％的CPU。 XML的压缩似乎在服务器上处理得更好（即解析/ CPU时间），而不是在.net gui上，但这可能是由于使用Microsoft XML库的上述不足所致。正如我提到的，有更好的库可用，它们速度更快，占用的内存更少。
在我们的情况下，我们在大小方面得到了巨大的改进 - 在某些情况下，我们将50兆XML文件压缩到了约10兆。这显然也有助于网络性能。
由于我们担心这会产生影响，以及是否会有其他后果（我们的用户似乎会在大浪中做事情，所以我们担心会用完CPU），因此我们有一个配置变量，可以用来打开/关闭gzip。我建议您也这样做。
另一件事：我们还在将XML文件存储在数据库之前对它们进行了压缩，这节省了约50％的空间（XML文件从几K到几兆不等，但大多数都相当小）。做所有事情可能比选择特定级别更容易区分何时使用压缩或不使用压缩。
我曾经参与的一个项目中，我们向运行.NET的客户端发送大量的XML数据（>10兆）。 （我不建议这样做，这只是我们发现自己处于的情况！）我们发现随着XML文件足够大，Microsoft XML库无法解析XML文件（即使在大于1吉字节的机器上，机器也会用完内存）。最终更改XML解析库有所帮助，但在此之前，我们启用了数据传输上的GZIP压缩，这有助于我们解析大型文档。在我们的两个基于Linux的WebSphere服务器上，我们能够相当容易地生成XML并对其进行gzip压缩。我认为，在同时执行此操作的50个用户（加载约10到20个这些文件）时，我们能够正常完成此操作，并且占用约50％的CPU。 XML的压缩似乎在服务器上处理得更好（即解析/ CPU时间），而不是在.net gui上，但这可能是由于使用Microsoft XML库的上述不足所致。正如我提到的，有更好的库可用，它们速度更快，占用的内存更少。
在我们的情况下，我们在大小方面得到了巨大的改进 - 在某些情况下，我们将50兆XML文件压缩到了约10兆。这显然也有助于网络性能。
由于我们担心这会产生影响，以及是否会有其他后果（我们的用户似乎会在大浪中做事情，所以我们担心会用完CPU），因此我们有一个配置变量，可以用来打开/关闭gzip。我建议您也这样做。
另一件事：我们还在将XML文件存储在数据库之前对它们进行了压缩，这节省了约50％的空间（XML文件从几K到几兆不等，但大多数都相当小）。做所有事情可能比选择特定级别更容易区分何时使用压缩或不使用压缩。
- Egwor
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接