我在HEROKU上的Ruby on Rails 6.0(Ruby v2.7.1(网站上忙于pdf生成。
目标：在运行中生成一个包含图片列表的pdf照片库。该库来自外部服务，由API导入。PDF每页应包含1或2张图像，并且可能很长(最多30/40页(。应该有多个用户为pdf服务，并且每分钟的请求可能超过10个。这在其他网站上充分发挥作用。
我尝试过的：我尝试了几种使用Rails生成pdf的方法，使用诸如wicked_pdf、pdf_kit(两者都基于wkhtmltopdf(或grover(基于puppeteer(之类的gem。当我在localhost时，我可以下载风格良好的pdf，速度很慢，但我能得到它们，但我在生产中遇到了很大的问题。
问题：
- 在生产环境(Heroku(中，由于wkhtmltopdf或木偶机占用了大约250Mb，我的段塞大小是巨大的(大约400兆字节(。这似乎严重影响了服务器的内存使用
- 创建PDF的请求非常慢，超过20秒，而且经常超时
- 在同样的请求之后，我看到内存使用量大幅增加。我希望在几次请求后就没记性了
- 即使我创建了只有几页的较小PDF，我也遇到了同样的问题
我已经尝试了的文档提供的几个版本的标准代码，它们都生成了pdf，但性能问题阻碍了它们在生产中的使用。应该有用的是有一些指导方针来了解如何进行。
我的问题：
- 使用后台作业可以解决超时问题？但我预计这并不能解决pdf创建时间过长的问题
- 在Heroku上使用更多的工人或工作是个好主意吗？这样可以提高PDF创建的性能吗
- 有没有其他方法的建议，或使用较轻的图书馆或服务
- 我可以考虑只生成一次pdf并将其保存在S3上，但数据是在另一台服务器上创建的，我通过API获取数据，我无法检查是否对其进行了任何修改
我从同一网站的老开发人员那里得到信息，我需要的相同的确切数据在几秒钟内通过FOP on.net和apache使用XML-XSLFO-PDF链提供，与Rails和Heroku完全不兼容。
在下面，我发布了一个版本的代码，用wicked_pdf-gem生成pdf，但这显然是我必须更新的内容。
def book_pdf
# code to generate the picture list and title of the gallery #
respond_to do |format|
format.html
format.pdf do
render pdf: @model_name.parameterize,
orientation: "Landscape",
page_size: 'A4',
show_as_html: false,
disposition: 'attachment',
header: { :html => { :template => 'pdf/book_header.pdf.erb' } },
footer: { :html => { :template => 'pdf/book_footer.pdf.erb' } },
quality: 50,
zoom: Rails.env.production? ? 0.81 : 1.00,
layout: "pdf.html"
end
end
end
WickedPdf.config = {
layout: 'pdf.html.erb',
print_media_type: true,
page_size: 'A4',
encoding: 'utf-8',
}
- 如果同一个pdf要提供给几个人，并且pdf本身不会经常更改，那么最好生成一次并将其存储在S3中，在应用程序中的DB记录中存储带有一些标识参数的URL
- 如果有几个人要求相同的pdf(没有数据更改(，并且它已经在S3中了(你可以从你的DB记录中识别(，你可以在没有新一代的情况下提供它
- 将PDF生成转移到sidekiq中的后台工作程序将真正为实际的http请求释放web应用程序，并防止当前的超时问题
- 拥有更多的工作人员可能会提高并发pdf请求的性能，但(在工作人员中(每次生成pdf所花费的时间不会提高
- 由于你说pdf只是图像，而你不知道其他服务器何时进行了更改，也许你可以在后台进行一项轮询工作，试图找出数据何时发生了更改，从而主动生成一个新的pdf，并在有人要求之前将其存储在S3上
- 当pdf在后台生成时，如果DB记录中有该pdf的识别标签，并且有人要求它(http请求(，您可以实现某种轮询或websocket流，用户的浏览器不断询问并等待服务器说pdf已经准备好了