「迅排设计」服务端生成图片压测报告

我们都知道 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)。

相关推荐
Code_流苏15 分钟前
如何使用Git参与GitHub开源项目:入门全流程
git·开源·github·开源项目·入门学习
JoernLee3 小时前
Qwen3术语解密:读懂大模型黑话
人工智能·开源·llm
伊织code4 小时前
PocketBase - 单文件开源后端解决方案
后端·开源·go·api·文件·pocketbase
ClkLog-开源埋点用户分析16 小时前
全开源、私有化部署!轻量级用户行为分析系统-ClkLog
开源·开源软件·sdk·用户画像·埋点分析
xinxiyinhe18 小时前
2025年深度学习模型发展全景透视(基于前沿技术突破与开源生态演进的交叉分析)
人工智能·深度学习·开源
沉默的松饼18 小时前
《商业世界的开源法则:协议选择与商业模式创新》
开源·开源协议
dapp040219 小时前
开源交易所源码,交易所开发
开源
亿坊电商19 小时前
开源CMS系统的SEO优化功能主要依赖哪些插件?
开源·cms·插件
量子位20 小时前
阿里 Qwen3 问鼎开源王座!8 款模型全面开放,最大杯全方位超越 R1/o1,网友:让开源再次伟大
人工智能·开源·通义灵码
小华同学ai1 天前
2.1k star! 抓紧冲,DeepChat:连接AI与个人世界的智能助手的开源项目
人工智能·ai·开源·github·工具