我正在使用 DOMPDF 从一个脚本生成大约 500 个报告。在生成大约 10-15 个 PDF 后,它的内存不足。
在调试中,看起来每次加载字体时都会加载 8M,但这似乎应该使用字体缓存代码来处理。
关于这里出了什么问题的任何想法?我想发布一个简单的代码片段,但其中大部分都被抽象为多个层,所以它不仅仅是一个简单的复制/粘贴。
我正在使用 DOMPDF 从一个脚本生成大约 500 个报告。在生成大约 10-15 个 PDF 后,它的内存不足。
在调试中,看起来每次加载字体时都会加载 8M,但这似乎应该使用字体缓存代码来处理。
关于这里出了什么问题的任何想法?我想发布一个简单的代码片段,但其中大部分都被抽象为多个层,所以它不仅仅是一个简单的复制/粘贴。
如果您使用的是 dompdf 0.6 beta,则内存错误是 dompdf 在呈现表格时进入的无限循环的结果。这是一个我无法解决的已知问题。
相关网址:
http://code.google.com/p/dompdf/issues/detail?id=34
http://code.google.com/p/dompdf/issues/detail?id=91
(你看到的错误是pdf PHP Fatal error: Allowed memory size of 268435456 bytes exhausted)
首先,如果这是为了任何远程商业,只需获取Prince XML。它比任何其他 HTML 到 PDF 解决方案都要好和快得多(我已经看过它们了)。节省的开发人员时间将很快收回成本。
其次,最快的解决方案可能是在单独的进程中打印每个报告以解决任何内存泄漏问题。如果这是从命令行运行的,那么外部循环就像一个 shell 脚本,它将为每个报告启动一个进程。如果它是从 Web 运行的,则如果您在可以执行此操作的操作系统上,则为每个脚本分叉一个进程。
正如 cletus 所指出的,使用 DOMPDF 最快的解决方案可能是在单独的进程中呈现每个报告。您可以编写一个主脚本来调用执行实际渲染的子脚本(使用 exec)。正如您在 DOMPDF 支持组的讨论中看到的那样,它似乎确实有可能提供一点性能提升。
如果没有某种说明问题的示例,就很难说出内存使用方面的其他情况。我不相信 DOMPDF 和底层 CPDF 渲染引擎在单个脚本中的多个实例没有太多优化。所以字体可能每次都被加载到内存中,即使它可以使用静态变量来缓存该数据。