c# - 压缩 XML 指标。

Question

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

有没有关于这个或例子的好的指标？

Answer 1

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

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

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

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

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

Answer 2

一个松散的度量标准是压缩比单个数据包更大的任何东西，但这只是吹毛求疵。

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

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

Answer 3

无论如何总是压缩它。

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

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 库的不足。正如我所提到的，有更好的库可用，它们更快并且使用更少的内存。

In our case, we got massive improvements in size too -- we were compressing 50 meg XML files in some cases down to about 10 meg. This obviously helped out network performance too.

Since we were concerned about the impact, and whether this would have other consequences (our users seemed to do things in large waves, so we were concerned we'd run out of CPU) we had a config variable which we could use to turn gzip on/off. I'd recommend that you do this too.

Another thing: we also zipped XML files before persisting them in databases, and this saved about 50% space (XML files ranging from a few K to a few meg, but mostly fairly small). It's probably easier to do everything than choose a specific level to differentiate when to use compression or not.