用PHP + DomPDF缓慢生成PDF [英] Slow PDF generation with PHP+DomPDF

查看:281
本文介绍了用PHP + DomPDF缓慢生成PDF的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我花了一段时间处理使用DomPDF的PDF生成过程非常缓慢。经过大量的摆弄和搜索之后,我最终得到了一个解决方案,我想我应该发布一个解决方案,以防你们中的一些人处理相同的问题。

I spent a while dealing with a really slow PDF generation process using DomPDF. After a lot of fiddling and googling, I eventually got a solution which I thought I'd post in case some of you are dealing with the same issue.

问题是:
我管理的电子商务网站具有允许卖方下载包含其已完成的采购订单的PDF文件的功能(基本上是显示给买方的购买确认书的副本)。一直都可以。
问题开始于我部署了一项附加功能,以允许卖方下载单个 PDF文件,并且所有购买订单在用户定义的日期之间生成。当需要导出为单个PDF(每页一个)的采购订单的数量超过20-30时,该过程变得异常缓慢(例如30-60秒)。

The problem: An e-commerce site I manage has the functionality to allow sellers to download a PDF file with the purchase orders they have fullfilled (basically a copy of the purchase confirmation shown to the buyer). That has always worked OK. The problem started when I deployed an additional functionality to allow sellers to download a single PDF file with all purchase orders generated between a user-defined set of dates. When the amount of purchase orders that needed to be exported as a single PDF (one per page) went over 20-30, the process became desperatingly slow (as in 30-60 seconds).

从数据库中获取数据并进行解析不是问题。构建随后导出到PDF中的视图也不是问题(即使将HTML发送到屏幕也需要几分之一秒的时间,即使是数百个订单),因此我基本上确定dompdf是问题。

Getting the data from the database and parsing it was not an issue. Building the view that was later exported into the PDF wasn't the issue either (outputting the HTML to the screen took a fraction of a second even for hundreds of orders), so I was basically sure that dompdf was the issue.

设置如下:
1.- MySQL数据库
2.-应用服务器:运行多个负载均衡的PHP + Nginx + PHP-fpm实例linux
3.- PHP 7.2
4.- dompdf 0.82(最新版本)
5.- Codeigniter 3.0.9
6.-用于格式化布局的引导程序

The setup was as follows: 1.- MySQL database 2.- App server: multiple load-balanced PHP+Nginx+PHP-fpm instances running linux 3.- PHP 7.2 4.- dompdf 0.82 (the latest one) 5.- Codeigniter 3.0.9 6.- Bootstrap for formatting the layout

目标是允许在可接受的时间内在单个PDF中下载多个(可能是数百个)采购订单。

The goal was to allow downloading multiple (potentially hundreds) of purchase orders in a single PDF in an acceptable time.

推荐答案

解决方案:

经过大量的搜索,反复试验后,在Stackoverflow上进行了大量查找(我发现的任何一篇文章都没有真正的帮助),我发现是导致问题的原因是引导程序。

After a lot of googling, trial and error, looking up a lot on Stackoverflow (none of the articles I found were really helpful), I figured out that it was bootstrap that was causing the issue.

我正在使用引导程序进行非常基本的布局管理我意识到将整个库(甚至是缩小的库)链接到发送到dompdf的视图中是过大的,但是我不想重写视图文件。

I was using bootstrap for very basic layout management and I realized that linking the whole library (even the minified one) into the view that was sent to dompdf was overkill, but I didn't want to re-write the view file.

因此,我采用了另一种方法:
获取我的视图正在使用的特定类(可能是6,可能是7)的CSS定义,并以< style> 标签中的视图

So, I took a different approach: Get the CSS definitions for the specific classes (6, maybe 7) my view was using and inline them in a <style> tag in the view

<style>
.row {
  margin-right: -15px;
  margin-left: -15px;
}
.col-xs-1, .col-sm-1, .col-md-1, .col-lg-1, .col-xs-2, .col-sm-2, .col-md-2, .col-lg-2, .col-xs-3, .col-sm-3, .col-md-3, .col-lg-3, .col-xs-4, .col-sm-4, .col-md-4, .col-lg-4, .col-xs-5, .col-sm-5, .col-md-5, .col-lg-5, .col-xs-6, .col-sm-6, .col-md-6, .col-lg-6, .col-xs-7, .col-sm-7, .col-md-7, .col-lg-7, .col-xs-8, .col-sm-8, .col-md-8, .col-lg-8, .col-xs-9, .col-sm-9, .col-md-9, .col-lg-9, .col-xs-10, .col-sm-10, .col-md-10, .col-lg-10, .col-xs-11, .col-sm-11, .col-md-11, .col-lg-11, .col-xs-12, .col-sm-12, .col-md-12, .col-lg-12 {
  position: relative;
  min-height: 1px;
  padding-right: 15px;
  padding-left: 15px;
}

.col-lg-12 {
    width: 100%;
}

.text-center {
  text-align: center;
}

body {
  font-family: Helvetica, Arial, sans-serif;
  font-size: 12px;
  line-height: 1.42857143;
  color: #333;
  background-color: #fff;
}
(...) the list goes on a little longer for some other bootstrap styles and other site-specific ones made by yours truly.
</style>

从视图中完全删除引导程序

重新测试,结果令人惊讶:
一张100采购订单(100页)PDF(大小小于60 kB)花费了30-60秒的时间生成并流式传输现在,它在不到半秒的时间内就向更改前的用户生成了,这证实了链接引导程序会在dompdf上产生巨大的开销,这在99%的用例中可能是不必要的。

retesting, the results were astonishing: A 100 purchase order (100-page) PDF (less than 60 kB in size) which took between 30-60 seconds to be generated and streamed to the user before the change, is now being generated in less than half a second, which confirmed that linking bootstrap produces a HUGE overhead on dompdf which is probably unnecesary in 99% of use cases.

希望这对某人有帮助。花了几天的时间才弄清楚。

Hope this helps someone. It took quite a few days of work to figure this out.

这篇关于用PHP + DomPDF缓慢生成PDF的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆