compression - 对微小的有效负载(<100 字节)使用压缩和解压缩的成本是多少？

Question

这是一个有点奇怪的情况。我知道真正的解决方案是深入开源并修复错误。但是请逗我...

我正在使用 GELF 标准将日志消息发送到 logstash(版本 5.0.0)。遗憾的是，logstash 的 GELF 解析器(Ruby gem gelfd:0.2.0)can only parse compressed messages .

对我来说阻力最小的方法就是压缩我的每条日志消息。即使它是 100 字节的消息。不会有有意义的大小优势(无论哪种方式都适合单个 UDP 数据报，并且其目的地是本地主机)，实际上文件 may become larger .

我担心我的应用程序会执行大量不必要的压缩 — 而我的 logstash 服务器会执行大量不必要的解压缩 — 只是为了解决 gelfd 中的这个错误>.

compression algorithms supported by GELF是 GZIP 和 ZLIB。

使用这些算法:尝试压缩然后解压缩一个小文件的计算成本有多大？

---

编辑:很抱歉在我自己没有做任何研究的情况下提交这个问题。作为忏悔:我现在已经提交了我自己的基准测试结果作为答案。

Answer 1

我已经为 GZIP 编写了一个基准测试脚本。

不完全代表:

• 不使用与 Java 程序将使用的完全相同的压缩器/解压缩器实现
• 不在与 Java 程序完全相同的运行时条件下运行
• 不测试各种字符串
• 不测试各种字符串大小

尽管如此，它还是提供了一个有用的启发。

plain="2016-11-09 20:56:02,469 ERROR [main] c.s.HelloExample - Something wrong with customer 'CUS-123e4567-e89b-12d3-a456-42665544'"

echo "Log message which we are using for this test is:"
echo $plain

echo "Time taken to echo this string 10,000 times:"

time for a in $(seq 1 10000);
do
    echo $plain > /dev/null
done

echo "Time taken to echo and compress this string 10,000 times:"

time for a in $(seq 1 10000);
do
    echo $plain | gzip -cf > /dev/null
done

echo "Time taken to echo, compress and decompress this string 10,000 times:"

time for a in $(seq 1 10000);
do
    echo $plain | gzip -cf | gzip -cfd > /dev/null
done

测量结果如下:

Log message which we are using for this test is:
2016-11-09 20:56:02,469 ERROR [main] c.s.HelloExample - Something wrong with customer 'CUS-123e4567-e89b-12d3-a456-42665544'
Time taken to echo this string 10,000 times:

real    0m1.940s
user    0m0.591s
sys 0m1.333s
user+sys 0m1.924s
Time taken to echo and compress this string 10,000 times:

real    0m22.028s
user    0m11.309s
sys 0m17.325s
user+sys 0m28.634s
Time taken to echo, compress and decompress this string 10,000 times:

real    0m22.983s
user    0m18.761s
sys 0m27.322s
user+sys 0m46.083s
[Finished in 47.0s real time]

User+sys shows how much CPU time was used ;这是计算计算密集程度的重要一点。

因此，与仅回显原始字符串相比，压缩需要大约 14.9 倍的计算量。

压缩 + 解压缩比仅回显原始字符串需要多 24.0 倍的计算。这仅比压缩多 1.6 倍的计算量。

结论:

• 用 GZIP 压缩即使是很小的文件也不便宜。
• GZIP 解压很便宜!

注意:实际上，该测试可能一直在测量 gzip 可执行文件的启动和清理成本。我不确定这些是否重要，但我们可以肯定地看到它是一个线程应用程序 (user + sys < real)。所以我可以想象启动 pthreads 等设置开销。

对于 GZIP 的时间复杂度与输入大小的关系，我无法找到任何结论性的答案。但知道会很有趣。