我有一个服务器端程序，可以为客户端生成JSON。我的一些同事建议使用zip / gzip压缩，以减少通过线路发送的数据量。但是，当针对我的一条普通JSON消息进行测试时，它们实际上都增加了发送的数据量。直到我发出一个异常大的回复，拉链才被踢进去并且很有用。
所以我开始讨论stackoverflow，我最终找到了LZO，经过测试，它确实完成了我想要它做的事情。但是，我似乎无法找到算法运行时间的文档，而且我不能很好地坐下来编写代码并自己弄明白：）
TL;博士？运行时间LZO？
答案 0 :(得分：8)
我将忽略你关于LZO运行时的问题（答案：几乎肯定足够快）并讨论潜在的问题。
您正在通过线路交换JSON数据结构，并希望减少带宽。目前您正在考虑通用压缩算法，如DEFLATE和LZO。但是，任何基于Lempel-Ziv技术的压缩算法都能最好地处理大量数据。这些算法通过building up a dictionary频繁出现的数据序列工作，因此它们可以在重复时编码对字典的引用而不是整个序列。字典越大，压缩率越高。对于非常少量的数据，例如单个数据包，该技术是无用的：没有时间来构建字典，并且没有时间出现大量重复。
如果您使用JSON编码有线协议，那么您的数据包很可能是刻板的，具有类似的结构和少量的公共密钥。因此，我建议调查专为此用例设计的Google Protocol Buffers。
答案 1 :(得分：4)
支持避免使用LZO和任何其他类型的通用/二进制数据压缩算法的建议。
您的其他选择基本上是：
最佳选择取决于您的服务器/语言设置，速度与压缩要求以及个人偏好。我可能会自己使用MessagePack，但你也不会错误地使用Protocol Buffers。