我们在多次通话时遇到有关fop（v0.95）表现的问题。我们正在创建包含一些图像和我们自己的字体的pdf。
第一次通话比其他通话要长得多，这对我们来说是一个问题。以下是一些调用示例（时间以毫秒为单位）：
我们尝试了几件事来解决这个问题：
在第一次通话时没有什么能显着改善表现。我们目前唯一的解决方案是在构造函数中生成一个假的pdf，这样第一次调用将在jvm start中人工完成。
你有什么建议来平滑表演，也许有关于这种行为的一些解释？
提前致谢。
答案 0 :(得分：0)
这是Java类加载和JIT（即时编译）的影响，即所谓的JVM预热。随着JVM的优化潜力，JVM逐渐提升了性能。如果你运行100个电话，你最终会看到或多或少不变的性能。你无法改变这一点，这同样适用于任何Java应用程序。
如果您当前正在运行服务器VM（默认使用64位CPU），也许您可以切换到客户端VM（-client作为JVM参数）。这可能会减少你看到的效果，但可能不会太多。
答案 1 :(得分：0)
生成的PDF中底层资源的更改频率是多少？
之前我和FOP合作过，并且遇到了大致相同的问题，从来没有找到一个干净的方法（即使可能有一个）。
事后我会尝试的一件事就是在底层资源被持久化时生成pdf;然后序列化它而不是按需渲染。然后，每当有请求进入时，只返回最近的序列化pdf。即使您可能最终生成从未使用过的PDF;它将大大减少用户获取PDF格式的时间;可能比你现在看到的时间更多。