使用Puppeter在node.js应用程序上执行密集pdf生成任务的可扩展性？

该应用程序的目标是使用Puppeter生成pdf，我们获取数据，构建html模板，然后使用chrome headless生成pdf，然后返回新生成pdf的链接

问题是，生成pdf大约需要7000毫秒，这主要是因为有三个傀儡功能：launch（启动headless broweser）、goto（导航到html模板）和pdf（生成pdf）

因此，有大约7~8秒的时间来回答一个请求，如果有更多的传入请求或突然出现峰值，30个同时请求很容易需要大约40~50秒，我认为这是不可接受的

在花了很多时间研究之后，我将实现集群模块以利用多个进程

---

除聚类外，还有其他可能的选项来优化单个实例上的时间吗？

< P>有一些要考虑的事情…

考虑调用

puppeter。每次启动应用程序时启动一次
。您的转换脚本只需检查浏览器实例是否已存在，并通过调用
newPage（）
使用它，这基本上是创建新选项卡，而不是每次创建浏览器

您可以考虑拦截<代码>请求<代码>为<代码>页面。在（“请求”，这个.OnPaGrErrestREST）；<代码>调用

goto（）

并过滤掉页面当前正在加载的某些类型的文件，但PDF呈现不需要它们；如果这是你的情况，你也可以过滤掉外部资源

使用

pdf（）

时，您可以从您的服务返回

Buffer

，而不是使用文件系统并返回指向创建的pdf文件位置的链接。这可能会加快速度，也可能不会，这取决于您的服务设置；无论如何，IO越少越好

这可能是你能为你的应用程序的单个实例所做的全部；通过上面的实现，我可以在1-2秒内完成常规（几页）PDF和一些图像的渲染

---

要加快速度，请使用集群。除了将其嵌入到应用程序中，您还可以考虑使用Manager来启动和缩放服务的多个实例。

是否需要为每个PDF文件执行启动和GOTO步骤？一开始可以做一次吗我只是想他们可以，但我记得大约一年前有一些问题，在压力测试中，一些pdf是空白的。谢谢你的建议！我正计划有一个类似的实现，我唯一担心的是一年前我在使用浏览器池时做的stess测试，一些pdf是空白的。你最近遇到过类似的事情吗？@PCS-I我描述了在我们的服务中实现的步骤，我们对PDF转换器的单个实例执行了大约40个线程的压力测试。它不能以这个比例扩展很多，但永远不会得到空白的PDF。这在我们的实现中是不可能的，因为我们将HTML流传递到node.js服务中，并获取生成的PDF的二进制文件。所有外部内容被阻止，以HTML作为数据URL提供的内联图像；空白PDF可能意味着您的服务已被淹没，某些请求超时，但这将是错误处理，而不是转换问题。