3

我有一个为客户端生成 JSON 的服务器端程序。我的一些同事建议使用 zip/gzip 压缩来减少通过网络发送的数据量。但是，当针对我的一条普通 JSON 消息进行测试时，它们实际上都增加了发送的数据量。直到我发送了一个异常大的回复，拉链才开始起作用并且很有用。

所以我开始研究 stackoverflow，最终找到了LZO，它在测试时完全符合我的要求。但是，我似乎找不到算法运行时间的文档，而且我还不够好，无法坐下来自己研究代码：)

tl;博士？LZO 的运行时间？

4

2 回答 2

8

我将忽略您关于 LZO 运行时的问题（答案：几乎可以肯定足够快）并讨论潜在问题。

您正在通过网络交换 JSON 数据结构并希望减少带宽。目前，您正在考虑使用DEFLATE和 LZO等通用压缩算法。然而，任何基于Lempel-Ziv技术的压缩算法在处理大量数据时效果最好。这些算法通过建立一个频繁出现的数据序列的字典来工作，这样它们就可以在重复时对字典的引用而不是整个序列进行编码。字典越大，压缩比越好。对于非常少量的数据，例如单个数据包，该技术是无用的：没有时间建立字典，也没有时间出现大量重复。

如果您使用 JSON 对有线协议进行编码，那么您的数据包很可能是定型的，具有相似的结构和少量的公共密钥。所以我建议研究专门为这个用例设计的谷歌协议缓冲区。

于 2011-07-15T13:03:18.233 回答
4

支持避免 LZO 和任何其他类型的通用/二进制数据压缩算法的建议。

您的其他选择基本上是：

最佳选择取决于您的服务器/语言设置、您的速度与压缩要求以及个人偏好。我自己可能会使用 MessagePack，但使用 Protocol Buffers 也不会出错。

于 2011-07-15T13:23:19.363 回答