Activepieces 生产环境怎么按峰值并发流程数计算 worker 与 app 数量并配置推荐参数【免费下载链接】activepiecesAI Agents MCPs AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows AI Agents • MCPs for AI Agents项目地址: https://gitcode.com/GitHub_Trending/ac/activepieces在 Activepieces 上生产环境的核心容量问题只有一个数字峰值并发流程数peak concurrent flows。官方推荐的生产形态是“一个 worker 只跑一个流程”worker 和 app 的数量、单实例规格、以及执行相关的环境变量都从这一个数字推导出来。本文按 Production Setup 给出的方法走一遍完整的计算与配置过程确定组件数量、拆分 app 与 worker 容器、配置推荐参数、启用 S3最后验证容量是否到位。计算模型worker 峰值并发流程数app worker / 10并发为 1 的 worker 会占用一个流程的整个运行时长最长 10 分钟所以容量按“同时有多少个流程在跑”来算而不是按触发速率workers peak concurrent flows apps ceil(workers / 10)官方文档给出的组件规格与数量规则如下组件单实例规格数量Worker0.5 vCPU / 1 GB并发 1每个并发流程一个App1 vCPU / 1 GB每 10 个 worker 一个Postgres托管2 vCPU / 4 GB起点值1 个按峰值吞吐扩容Redis托管1 vCPU / 1 GB1 个对象存储S3与计算同区域开启签名 URL必需代入示例峰值并发 50 个流程 →50 个 worker合计 25 vCPU / 50 GB5 个 app合计 5 vCPU / 5 GB。超出容量的请求会排队在 Redis 中等 worker 空出槽位后再执行。有两个直接影响计算的约束Postgres 不随 worker 数量静止。Benchmark 的测量显示数据库 CPU 跟吞吐走大约每 req/s 消耗 2.5 millicores官方明确说 2 vCPU 只是小规模集群的起点要随集群一起扩容不能只把 worker 数量当唯一旋钮。按峰值静态预置。Autoscaling 的实测数据表明热节点上新 worker 约 5 s 就绪但需要新节点时要 ~85–90 s赶不上同步 webhook 的 30 s 响应预算。因此建议把最小副本数保持在同步 webhook 的峰值之上再把峰值以上的突发余量交给自动伸缩。配置推荐执行参数Production Setup 给出的推荐配置正是 benchmark 测量所用的执行参数AP_WORKER_CONCURRENCY1 AP_REUSE_SANDBOXtrue AP_EXECUTION_MODESANDBOX_CODE_ONLY AP_FILE_STORAGE_LOCATIONS3 AP_S3_USE_SIGNED_URLStrue注意这些变量放在哪一侧容器拆分的部署app 与 worker 分开AP_WORKER_CONCURRENCY、AP_REUSE_SANDBOX、AP_EXECUTION_MODE设在worker容器上S3 相关的两个变量设在app容器上。单容器同时跑两种角色AP_CONTAINER_TYPEWORKER_AND_APP默认值全部设在这一个容器上。两点需要知道的边界出厂默认AP_WORKER_CONCURRENCY5是过渡性的兼容模式一个容器里跑多个沙箱会扩大 OOM 影响面Workers 与 Limits 都建议改为 1 并用副本数扩容。如果暂时不想改形态可以保留并发 5但每个 worker 要按约 5 倍规格≈5 GB给。使用 Worker Groups给特定项目预留专属 worker 池时分组 worker 必须保持AP_EXECUTION_MODESANDBOX_PROCESScode-only 模式会被拒绝并且AP_REUSE_SANDBOX必须显式设置true 或 false。这是本文主路径的一个可选分支只有需要给租户/项目做容量隔离时才引入。S3 是生产形态的硬性要求而非可选项没有它所有 flow bundle 和 piece 存档都会挤过 app 层上面引用的吞吐数据不再成立。完整环境变量bucket、密钥、region 等见 S3 Storage。前提把 app 和 worker 拆成两种容器推荐形态是“薄的 app 层 并发 1 的 worker 层”。如果你现在跑的是默认的单容器同一镜像同时提供 API/UI 和内嵌 worker按 Separate Workers 的路径操作先在下层环境验证再上生产现有容器改为 app。设置AP_CONTAINER_TYPEAPP它就不再拉取流程只提供 API 和 UI。默认值是WORKER_AND_APP不设这个变量的话 app 会继续跑内嵌 worker。生成 worker token。用 CLI 生成输入与 app 相同的AP_JWT_SECRETtoken 会打印在终端npx activepieces/cli workers token新起 worker 容器只设三个环境变量worker 不持有 Redis 或数据库凭据仅通过AP_FRONTEND_URL访问 appAP_CONTAINER_TYPEWORKER AP_FRONTEND_URLhttps://your-instance-url AP_WORKER_TOKEN第一步生成的 token其中AP_FRONTEND_URL替换为你实例的公网 URLworker 访问$AP_FRONTEND_URL/apiAP_WORKER_TOKEN替换为上一步生成的 token。再叠加推荐执行参数AP_WORKER_CONCURRENCY1、AP_REUSE_SANDBOXtrue、AP_EXECUTION_MODESANDBOX_CODE_ONLY。保持总槽位不变slots 容器数 × 并发数。官方迁移示例改造前 10 个 worker × 并发 5每个约 2.5 vCPU / 5 GB改造后 50 个 worker × 并发 1每个 0.5 vCPU / 1 GB总槽位都是 50。验证确认 worker 在线并压测定位瓶颈第一步确认 worker 被 app 识别。在 Platform Admin Console 的 Infra → Workers 页面确认所有 worker 可见、在线。第二步用官方 CLI 对自己部署做压测诊断。它会创建一个一次性项目跑完自动删除不碰你的真实项目发布一个同步 webhook 流程打流量并输出一份分阶段的诊断报告AP_API_KEY平台管理员 API key npx activepieces/clilatest benchmark --url https://your-instance.example.com其中AP_API_KEY替换为你的平台管理员级 API key--url替换为你实例的地址。并发数默认等于你的执行槽位数所有已连接 worker 的AP_WORKER_CONCURRENCY之和保证请求不会在并发 1 的 worker 后面排队测到的是真实服务时间。输出里的关键判读来自 Benchmark 文档QUEUE大且 queue depth 持续增长 → 驱动的并发超过了槽位数是容量不足而非服务慢RUN≫ 200 ms → 流程本身更重或 worker CPU 不足storage≫ 240 ms → 对象存储跨区或限流报告结尾的 verdict 会给出queue-bound并发超槽位还是service-bound真实引擎耗时的结论。文档给过一份小规模部署的示例输出4 worker、并发 4、200 请求其中 RUN p50 约 201 ms、verdict 为 service-bound。这是文档示例不是你必须复现的固定数值你的流程重量和硬件不同数值会不同判读方法一样逐层比较、定位占主导的那一层。规模扩大时的已知边界超过 ~80 个 worker 后worker 不再是唯一旋钮。benchmark 实测GKE、1:10 配比、S3 签名 URL、同区域对象存储40/80/120/160 worker 对应 213 / 484 / 641 / 777 req/s单 worker 速率在 80 worker 处达峰6.1 req/s后回落约 20%。原因是共享的数据库 CPU 随吞吐线性增长官方结论是“随集群一起扩容 Postgres”但该 benchmark 未证明数据库就是瓶颈只是给出了审慎的扩容方向。1:10 配比的依据app 单核在每一档负载下稳定在 ~0.52–0.61 核是突发时 app 层不先成为墙面的余量。worker 崩溃可恢复worker 无状态Redis 租约丢失或进程崩溃时 BullMQ 会重排任务由其他 worker 接管并跳过已完成步骤滚动 worker 前不需要先排空流量详见 Guarantees。与容量相关的关键限制默认值/环境变量流程运行超时 600 sAP_FLOW_TIMEOUT_SECONDS、同步 webhook 响应 30 sAP_WEBHOOK_TIMEOUT_SECONDS、webhook 载荷 25 MB、单流程文件 25 MBAP_MAX_FILE_SIZE_MB。并发 1 时 worker 容器 1 GB 内存上限就是流程的内存上限超出会被 OOM 并重新排队更大或更长的处理应拆成多个流程。完整的限制表在 Limits扩容决策的完整实测数据容量到达时间、缩容安全性在 Autoscaling。【免费下载链接】activepiecesAI Agents MCPs AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows AI Agents • MCPs for AI Agents项目地址: https://gitcode.com/GitHub_Trending/ac/activepieces创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Activepieces 生产环境怎么按峰值并发流程数计算 worker 与 app 数量并配置推荐参数？
Activepieces 生产环境怎么按峰值并发流程数计算 worker 与 app 数量并配置推荐参数【免费下载链接】activepiecesAI Agents MCPs AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows AI Agents • MCPs for AI Agents项目地址: https://gitcode.com/GitHub_Trending/ac/activepieces在 Activepieces 上生产环境的核心容量问题只有一个数字峰值并发流程数peak concurrent flows。官方推荐的生产形态是“一个 worker 只跑一个流程”worker 和 app 的数量、单实例规格、以及执行相关的环境变量都从这一个数字推导出来。本文按 Production Setup 给出的方法走一遍完整的计算与配置过程确定组件数量、拆分 app 与 worker 容器、配置推荐参数、启用 S3最后验证容量是否到位。计算模型worker 峰值并发流程数app worker / 10并发为 1 的 worker 会占用一个流程的整个运行时长最长 10 分钟所以容量按“同时有多少个流程在跑”来算而不是按触发速率workers peak concurrent flows apps ceil(workers / 10)官方文档给出的组件规格与数量规则如下组件单实例规格数量Worker0.5 vCPU / 1 GB并发 1每个并发流程一个App1 vCPU / 1 GB每 10 个 worker 一个Postgres托管2 vCPU / 4 GB起点值1 个按峰值吞吐扩容Redis托管1 vCPU / 1 GB1 个对象存储S3与计算同区域开启签名 URL必需代入示例峰值并发 50 个流程 →50 个 worker合计 25 vCPU / 50 GB5 个 app合计 5 vCPU / 5 GB。超出容量的请求会排队在 Redis 中等 worker 空出槽位后再执行。有两个直接影响计算的约束Postgres 不随 worker 数量静止。Benchmark 的测量显示数据库 CPU 跟吞吐走大约每 req/s 消耗 2.5 millicores官方明确说 2 vCPU 只是小规模集群的起点要随集群一起扩容不能只把 worker 数量当唯一旋钮。按峰值静态预置。Autoscaling 的实测数据表明热节点上新 worker 约 5 s 就绪但需要新节点时要 ~85–90 s赶不上同步 webhook 的 30 s 响应预算。因此建议把最小副本数保持在同步 webhook 的峰值之上再把峰值以上的突发余量交给自动伸缩。配置推荐执行参数Production Setup 给出的推荐配置正是 benchmark 测量所用的执行参数AP_WORKER_CONCURRENCY1 AP_REUSE_SANDBOXtrue AP_EXECUTION_MODESANDBOX_CODE_ONLY AP_FILE_STORAGE_LOCATIONS3 AP_S3_USE_SIGNED_URLStrue注意这些变量放在哪一侧容器拆分的部署app 与 worker 分开AP_WORKER_CONCURRENCY、AP_REUSE_SANDBOX、AP_EXECUTION_MODE设在worker容器上S3 相关的两个变量设在app容器上。单容器同时跑两种角色AP_CONTAINER_TYPEWORKER_AND_APP默认值全部设在这一个容器上。两点需要知道的边界出厂默认AP_WORKER_CONCURRENCY5是过渡性的兼容模式一个容器里跑多个沙箱会扩大 OOM 影响面Workers 与 Limits 都建议改为 1 并用副本数扩容。如果暂时不想改形态可以保留并发 5但每个 worker 要按约 5 倍规格≈5 GB给。使用 Worker Groups给特定项目预留专属 worker 池时分组 worker 必须保持AP_EXECUTION_MODESANDBOX_PROCESScode-only 模式会被拒绝并且AP_REUSE_SANDBOX必须显式设置true 或 false。这是本文主路径的一个可选分支只有需要给租户/项目做容量隔离时才引入。S3 是生产形态的硬性要求而非可选项没有它所有 flow bundle 和 piece 存档都会挤过 app 层上面引用的吞吐数据不再成立。完整环境变量bucket、密钥、region 等见 S3 Storage。前提把 app 和 worker 拆成两种容器推荐形态是“薄的 app 层 并发 1 的 worker 层”。如果你现在跑的是默认的单容器同一镜像同时提供 API/UI 和内嵌 worker按 Separate Workers 的路径操作先在下层环境验证再上生产现有容器改为 app。设置AP_CONTAINER_TYPEAPP它就不再拉取流程只提供 API 和 UI。默认值是WORKER_AND_APP不设这个变量的话 app 会继续跑内嵌 worker。生成 worker token。用 CLI 生成输入与 app 相同的AP_JWT_SECRETtoken 会打印在终端npx activepieces/cli workers token新起 worker 容器只设三个环境变量worker 不持有 Redis 或数据库凭据仅通过AP_FRONTEND_URL访问 appAP_CONTAINER_TYPEWORKER AP_FRONTEND_URLhttps://your-instance-url AP_WORKER_TOKEN第一步生成的 token其中AP_FRONTEND_URL替换为你实例的公网 URLworker 访问$AP_FRONTEND_URL/apiAP_WORKER_TOKEN替换为上一步生成的 token。再叠加推荐执行参数AP_WORKER_CONCURRENCY1、AP_REUSE_SANDBOXtrue、AP_EXECUTION_MODESANDBOX_CODE_ONLY。保持总槽位不变slots 容器数 × 并发数。官方迁移示例改造前 10 个 worker × 并发 5每个约 2.5 vCPU / 5 GB改造后 50 个 worker × 并发 1每个 0.5 vCPU / 1 GB总槽位都是 50。验证确认 worker 在线并压测定位瓶颈第一步确认 worker 被 app 识别。在 Platform Admin Console 的 Infra → Workers 页面确认所有 worker 可见、在线。第二步用官方 CLI 对自己部署做压测诊断。它会创建一个一次性项目跑完自动删除不碰你的真实项目发布一个同步 webhook 流程打流量并输出一份分阶段的诊断报告AP_API_KEY平台管理员 API key npx activepieces/clilatest benchmark --url https://your-instance.example.com其中AP_API_KEY替换为你的平台管理员级 API key--url替换为你实例的地址。并发数默认等于你的执行槽位数所有已连接 worker 的AP_WORKER_CONCURRENCY之和保证请求不会在并发 1 的 worker 后面排队测到的是真实服务时间。输出里的关键判读来自 Benchmark 文档QUEUE大且 queue depth 持续增长 → 驱动的并发超过了槽位数是容量不足而非服务慢RUN≫ 200 ms → 流程本身更重或 worker CPU 不足storage≫ 240 ms → 对象存储跨区或限流报告结尾的 verdict 会给出queue-bound并发超槽位还是service-bound真实引擎耗时的结论。文档给过一份小规模部署的示例输出4 worker、并发 4、200 请求其中 RUN p50 约 201 ms、verdict 为 service-bound。这是文档示例不是你必须复现的固定数值你的流程重量和硬件不同数值会不同判读方法一样逐层比较、定位占主导的那一层。规模扩大时的已知边界超过 ~80 个 worker 后worker 不再是唯一旋钮。benchmark 实测GKE、1:10 配比、S3 签名 URL、同区域对象存储40/80/120/160 worker 对应 213 / 484 / 641 / 777 req/s单 worker 速率在 80 worker 处达峰6.1 req/s后回落约 20%。原因是共享的数据库 CPU 随吞吐线性增长官方结论是“随集群一起扩容 Postgres”但该 benchmark 未证明数据库就是瓶颈只是给出了审慎的扩容方向。1:10 配比的依据app 单核在每一档负载下稳定在 ~0.52–0.61 核是突发时 app 层不先成为墙面的余量。worker 崩溃可恢复worker 无状态Redis 租约丢失或进程崩溃时 BullMQ 会重排任务由其他 worker 接管并跳过已完成步骤滚动 worker 前不需要先排空流量详见 Guarantees。与容量相关的关键限制默认值/环境变量流程运行超时 600 sAP_FLOW_TIMEOUT_SECONDS、同步 webhook 响应 30 sAP_WEBHOOK_TIMEOUT_SECONDS、webhook 载荷 25 MB、单流程文件 25 MBAP_MAX_FILE_SIZE_MB。并发 1 时 worker 容器 1 GB 内存上限就是流程的内存上限超出会被 OOM 并重新排队更大或更长的处理应拆成多个流程。完整的限制表在 Limits扩容决策的完整实测数据容量到达时间、缩容安全性在 Autoscaling。【免费下载链接】activepiecesAI Agents MCPs AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows AI Agents • MCPs for AI Agents项目地址: https://gitcode.com/GitHub_Trending/ac/activepieces创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 RELATED READING
延伸阅读
更多一线实战笔记与深度复盘，助您持续精进
