FOP，在 pdf 生成上获得稳定的性能

Question

我们遇到了关于 fop (v0.95) 在多次通话中的表现的问题。我们正在创建包含一些图像和我们自己的字体的 pdf。

第一个电话比其他电话要长得多，这对我们来说是个问题。以下是一些调用示例（时间以毫秒为单位）：

• 调用 #1 - 经过的时间 = 13929
• 调用 #2 - 经过的时间 = 2817
• 调用 #3 - 经过的时间 = 3312
• 调用 #4 - 经过的时间 = 1629
• 调用 #5 - 经过的时间 = 1436
• 调用 #6 - 经过的时间 = 1356
• 呼叫 #7 - 经过的时间 = 911
• 调用 #8 - 经过的时间 = 1244
• 调用 #9 - 经过的时间 = 780
• 调用 #10 - 经过的时间 = 895

我们尝试了几种方法来解决这个问题：

1. 使用目录参数加载我们的字体，或者加载 每种字体都带有字体标签
2. 将 stric-configuration 设置为 true
3. 将严格验证设置为 false
4. 使用缓存文件（缓存文件标签）

在第一次调用时没有显着提高性能。我们目前唯一的解决方案是在构造函数中生成一个假的 pdf，这样第一次调用将在 jvm 启动时人工完成。

你有什么建议可以让表演更流畅，或者对这种行为有一些解释吗？

提前致谢。

Answer 1

这是 Java 类加载和 JIT（即时编译）的效果，即所谓的 JVM 预热。 JVM 在看到优化潜力时逐渐提高了性能。例如，如果您运行 100 次调用，您最终会看到或多或少稳定的性能。您根本无法改变这一点，这同样适用于任何 Java 应用程序。

如果您当前正在运行服务器虚拟机（默认为 64 位 CPU），也许您可​​以切换到客户端虚拟机（-client 作为 JVM 参数）。这可能会稍微减轻您看到的效果，但可能不会太大。

Answer 2

生成的 PDF 中的基础资源多久更改一次？

我以前曾与 FOP 合作过，并且遇到过大致相同的问题，但从未找到解决它的干净方法（即使可能有一个）。

事后我会尝试的一件事是在底层资源持续存在时生成 pdf；然后序列化它而不是按需渲染。然后，只要有请求进来，就返回最新的序列化 pdf。即使您最终可能会生成从未使用过的 PDF；它将大大减少用户获取 pdf 的时间；可能比你现在看到的时代更是如此。