如何缩短GZIPOutputStream的时间

Question

我尝试过gzip一个大型(100 do到500 do) xml文件，我创建了方法Zip。问题是，它对zip.for 200 xml的时间太长，需要1.2秒。我需要减少100毫秒的时间来处理100 xml的xml文件。如何优化以减少拉链的时间？

我减少了时间，减少了对压缩比的小妥协。尝试了另一种算法，如Snappy、Lz4，但改进不多，而且它们的compression.as也很差，据我所知，gzipOutputStream.write()占用了85%的time.so，如何优化这个步骤以获得更好的性能，而不影响很大程度的压缩比。

public static String zip(final String str) {
    if ((str == null) || (str.length() == 0)) {
        throw new IllegalArgumentException("Cannot zip null or empty string");
    }

    try (ByteArrayOutputStream byteArrayOutputStream = new ByteArrayOutputStream(str.length())) {
        try (GZIPOutputStream gzipOutputStream = new GZIPOutputStream(byteArrayOutputStream){{def.setLevel(Deflater.BEST_SPEED );}};) {
            gzipOutputStream.write(str.getBytes(StandardCharsets.UTF_8));

        } 
            T5 = System.currentTimeMillis();
            byte[] bytes=byteArrayOutputStream.toByteArray();
             T3 = System.currentTimeMillis();

            String zipped_text=DatatypeConverter.printBase64Binary(bytes);
             T4 = System.currentTimeMillis();
            return zipped_text;

    } catch(IOException e) {
        throw new RuntimeException("Failed to zip content", e);
    }

}

Answer 1

以下是我的建议：

1. 创建一个适当的基准，以便您可以获得可重复的结果。我建议采用基准架构，例如JMH。
2. 分析您的代码/基准以确定瓶颈/热点所在；例如使用jVisualVM或Java任务控制飞行记录器。
3. 使用基准测试和分析结果指导您的优化工作。

(出于各种原因，我不会简单地依赖于对System.currentTimeMillis()的调用。)

一种可能的解释是，在以下步骤中，很大一部分时间用于数据复制。

• 创建包含XML的输入字符串
• 捕获ByteArrayOutputStream中的压缩字节
• 将字节串成另一个字符串。

因此，如果您正在寻找改善这种情况的方法，请尝试安排一些事情，以便XML序列化程序写入通过gzip和base64转换流数据的管道，然后直接写入文件或套接字流。

此外，如果可能的话，我将避免使用base64。如果压缩的XML位于HTTP响应中，则应该能够以二进制方式发送它。它将更快，并产生明显较少的网络流量。

最后，选择一种压缩算法，在压缩比和压缩时间之间做出很好的折中。

如何优化这一步骤，以获得更好的性能，而不影响压缩比。

如果你想这么做，你的目标可能是错的。(那么为什么Base64会对压缩文件进行编码呢？这违背了你的目标！)

更新以回应您的评论：

1. 您将(我认为)通过流获得更好的性能，而不是将XML转换为字符串，然后在其上调用getBytes()。首先，getBytes()调用正在对字符串内容进行不必要的复制。
2. 无损压缩上的维基百科页面链接到许多算法，其中许多算法应该有现成的Java实现。此外，它还有一些基准的链接。我还没有看过基准链接，但我希望至少有一个将量化不同算法的压缩与计算时间的权衡。
3. 如果将数据库表从CLOB更改为BLOB：

- you can dispense with the base64, saving ~25% storage space
- you can dispense with the base64 encoding step, saving a few percent of CPU
- you can then pick a faster (but less compact) algorithm, saving more time at the cost of some of the space that you saved by going to a BLOB.

​

1. “我不能改变它的业务要求。”-真的吗？如果数据库模式是业务需求，那么您的业务就会有问题。另一方面，如果企业在那个层面上决定技术，那么他们也决定了性能。 没有合理的技术理由将压缩数据存储为CLOBs。
2. 正如有人指出的，获得更快压缩的最简单的方法是购买一台更快的计算机。或者(我的想法)一堆计算机，这样你就可以并行压缩多个文件。