FOP，在 pdf 生成方面获得稳定的性能
我们在多次调用时遇到有关 fop (v0.95) 性能的问题。我们正在创建包含一些图像和我们自己的字体的 pdf。
第一个电话比其他电话要长得多，这对我们来说是一个问题。以下是一些呼叫示例（时间以毫秒为单位）：
- 呼叫 #1 - 已用时间 = 13929
- 呼叫 #2 - 已用时间 = 2817
- 呼叫 #3 - 已用时间 = 3312
- 呼叫 #4 - 已用时间 = 1629
- 呼叫 #5 - 已用时间= 1436
- 呼叫 #6 - 经过时间 = 1356
- 呼叫 #7 - 经过时间 = 911
- 呼叫 #8 -已用时间 = 1244
- 调用 #9 - 已用时间 = 780
- 调用 #10 - 已用时间 = 895
我们尝试了几种方法来解决此问题：
- 使用目录参数加载字体或加载 带有字体标签的每种字体
- 将 stric-configuration 设置为 true
- 将 strict-validation 设置为 false
- 使用缓存文件（缓存文件标签）
首次调用时没有任何显着改善性能。目前我们唯一的解决方案是在构造函数中生成一个假的 pdf，因此第一次调用将在 jvm 启动时人为地完成。
您有什么建议可以使表演更加流畅吗？也许对这种行为有一些解释？
提前致谢。
We are having issues regarding fop (v0.95) performances on multiples calls. We are creating pdf containing a few images and our own fonts.
The first call is by far longer than the others and it's a problem for us. Here are some call examples (times are in ms) :
- Call #1 - Elapsed time = 13929
- Call #2 - Elapsed time = 2817
- Call #3 - Elapsed time = 3312
- Call #4 - Elapsed time = 1629
- Call #5 - Elapsed time = 1436
- Call #6 - Elapsed time = 1356
- Call #7 - Elapsed time = 911
- Call #8 - Elapsed time = 1244
- Call #9 - Elapsed time = 780
- Call #10 - Elapsed time = 895
We tried several thing to fix this :
- Loading our font using the directory parameter instead or loading
each font with the font tag - Setting stric-configuration to true
- Setting strict-validation to false
- Using the cache file (cache-file tag)
Nothing significantly improve performances on first call. Our only solution for the moment is to generate a fake pdf in the constructor so the first call will be artificially done at jvm start.
Do you have any suggestion to smooth the performances, and maybe some explanations about this behavior ?
Thanks in advance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这是 Java 类加载和 JIT（即时编译）的效果，即所谓的 JVM 预热。当 JVM 看到优化潜力时，性能逐渐提高。如果您运行 100 次调用，您最终会看到或多或少稳定的性能。您根本无法改变这一点，这同样适用于任何 Java 应用程序。
如果您当前正在运行服务器 VM（默认使用 64 位 CPU），也许您可以切换到客户端 VM（-client 作为 JVM 参数）。这可能会稍微减轻您看到的效果，但可能不会太大。
That's an effect of Java class loading and JIT (just-in-time compiling), the so-called JVM warm-up. The JVM improves on the performance gradually as it sees optimization potential. If you run, say, 100 calls, you'll eventually see more or less constant performance. There's simply nothing you can do to change this, and the same applies to any Java application.
Maybe you can switch to the Client VM (-client as JVM parameter) if you're currently running the Server VM (which is default with a 64bit CPU). That might lessen the effect you see a bit, but probably not much.
生成的 PDF 中的底层资源多久更改一次？
我以前曾使用过 FOP，遇到过大致相同的问题，但从未找到一种干净的方法来解决它（尽管可能有一个）。
事后我会尝试的一件事是，只要底层资源被持久化，就生成 pdf 文件；然后将其序列化，而不是按需渲染。然后，每当收到请求时，只需返回最新的序列化 pdf。即使您最终可能生成从未使用过的 PDF；它将大大减少用户获取 pdf 的时间；可能比你现在看到的时代更是如此。
How often do the underlying resources change in the generated PDF?
I've worked with FOP before and had roughly the same issues and never found a clean way around it (even though there may be one).
The one thing I would have tried in hindsight would be to generate the pdf whenever the underlying resources are persisted; and then serialize it as opposed to rendering on demand. Then, whenever a request comes in just return the most recent serialized pdf. Even though you might end up generating PDFs that are never used; it will drastically reduce the time for the user to get their pdf; likely more so than the times you're seeing now.