迁移至2代Google Cloud Functions后的性能问题与配置咨询

问题根源解析 #

你遇到的Handlebars渲染耗时暴增、Puppeteer生成PDF失败，核心原因是GCF 2代基于Cloud Run构建，默认采用CPU仅在请求处理阶段分配的模式。这种模式下，实例空闲时CPU会被大幅节流，哪怕是同步的Handlebars渲染操作，也会因CPU资源不足导致耗时飙升；而Puppeteer需要持续CPU资源启动浏览器、渲染页面，节流状态下直接无法正常运行。开启“CPU always allocated”后，实例全程保持CPU资源分配，自然解决了性能问题，但也带来了成本顾虑。

你的疑问解答 #

1. 请求增多时会发生什么？ #

因为你配置了每个实例最多处理1个请求，当请求量超过当前运行的实例数量时，Cloud Run会自动启动新实例处理额外请求，直到达到你设置的最大实例数上限。若请求量继续增长，超出上限的请求会进入队列等待，直到有实例空闲。

2. 是否每个请求都会冷启动新实例？ #

不会。Cloud Run会根据流量模式保留一定数量的空闲实例，新请求优先分配给空闲实例，避免冷启动。只有当所有存活实例都在处理请求，且未达到最大实例数时，才会冷启动新实例。

3. 实例的存活时长是多少？ #

默认情况下，空闲实例会在15分钟左右被自动终止，但这个时长是Cloud Run动态调整的，没有绝对固定值。后续有新请求时，会重新启动实例（可能是热启动或冷启动，取决于是否有保留的空闲实例）。

4. 无流量时实例是否会自动终止？ #

会。当没有请求持续一段时间后，所有空闲实例都会被Cloud Run自动终止，停止消耗资源，这是默认的成本优化机制。

5. “CPU always allocated”意味着什么？ #

该模式下，实例从启动到终止的整个生命周期内，CPU资源会持续分配，不会因实例空闲而节流。哪怕实例没在处理请求，CPU也能保持正常性能。但代价是空闲实例也会消耗CPU资源，成本比默认模式更高，适合需要持续CPU资源、对响应速度要求极高的场景。

优化建议 #

• 适配默认模式优化代码：预编译Handlebars模板（避免每次请求重复编译），给Puppeteer添加启动优化参数（如--no-sandbox、--disable-dev-shm-usage、--single-process等），降低CPU资源消耗，尝试在默认模式下正常运行。
• 调整实例资源配置：若默认模式性能不足，可尝试给实例分配更多CPU/内存（比如从1CPU调整到2CPU），提升单实例处理能力，可能无需开启“CPU always allocated”即可解决问题。
• 设置合理的最大实例数：根据业务流量峰值，设置合适的最大实例数上限，避免请求突增时过度扩容导致成本失控。

内容的提问来源于stack exchange，提问作者Matteo Rossi