我们都知道 puppeteer 是比较占用 cpu 和内存的，迅排设计采用从服务端截图的方式来生成图片存在一个问题：启动消耗会比较大，因此有些朋友会担心服务器是否能够承受住压力，这篇文章就用实验和数据来解答这个疑问。
本服务代码均有开源，可前往 Github 仓库查看。代码里做了异步队列、并发阈值限制和熔断机制等处理，当然你也可以自行开发实现，源码仅供参考。
下面我们通过使用专业接口测试工具 Jmeter 以及可视化工具对性能和功能分别进行验证。
并发测试
以下使用软件为 Apache JMeter (5.6.3) 进行压力测试，测试服务器配置为 1 核 2G 内存，图片生成服务设置并发数上限为 2 个，熔断阈值为 20 个任务。
经过 Jmeter 测试后汇总结果如下所示，其中接口异常率为 0%，这表明即使在极低配置下的服务器依然能扛得住极高并发请求：
1000 并发时响应结果时间呈梯度上升趋势，预期完成 20 个任务，实际有 39 个任务成功返回图片生成结果。
其它任务则是被熔断了，此时用户在前台会接收到友好的提示：
功能测试
除了并发压力测试，我们继续使用可视化工具来进行功能测试。以 Apifox 为例，设置线程数为2，循环依次发起 20 次、50次、100次图片生成请求，测试服务器配置为1核2 G内存，显示结果如下（此软件无法正常并发，请求基本上都是同步执行，所有测试结果均正常返回图片）。
可以看到这组三次重复循环请求中，随着请求总数增加，平均接口请求耗时仍然非常接近，说明重复启停无头浏览器并不容易引起服务端波动，符合预期。
接下来我们让软件模拟 10 个用户不间断下载图片，持续 1 分钟：
结果在测试中总共发起请求数 80 次，最小响应时间在 2 秒左右，最大响应时间 8 秒左右。
总结
在正常情况下，用户请求下载一张图片平均出图速度在 3 ~ 7 秒内可以得到结果。在极高并发下，用户请求可能需要排队等待，最长等待 30 秒得到结果，其它请求则按一定规则熔断。
看到这里有的朋友可能会问，从数据上看 1000 并发的时候用户下载图片的完成率不是只有 4% 吗？对于这个结果我们还是要辩证地来看，首先用户进行在线设计其实大部分时间都是在"编辑"，不会一直需要下载图片，如果你的产品真的并发了 1000 个下载请求，那么同时在线人数少说也要有好几千，有这么强大的用户基础完全可以考虑升级配置或增加服务器。
另外，以上测试均在 1 核 2G 内存配置的机器下进行，且限制了一定的并行任务数和阈值，为的是确保下限，实际上不可能有比这还贫瘠的配置条件了。根据不同的配置，在服务器可承受的范围内调高并行数和阈值，应对高并发时完成率也会大幅上升。当然，用户的作品数据是保存在服务端的，即使因为等待资源分配而没能下载图片，也完全可以再次操作下载。
迅排设计自上线以来网站 uv 数已超过 25000+，微信登录人数 800+，用户共计创建了 5000+ 设计作品，至今图片生成服务仍稳定运行，相信应对绝大多数业务场景是游刃有余的。当然以上实验还忽略了服务器带宽限制、用户网络速度这些客观因素，实际也会在一定程度上影响用户下载作品的时间（本实验中服务器带宽为 2 M）。