Firebase Functions配额超限咨询：PDF转Image服务遇429错误

我来帮你理清这两个困惑，我之前做Serverless服务时也碰到过类似的配额坑，咱们一步步拆解：

一、为什么会触发CPUMilliSecondsNonbillable配额超限？ #

你之前的计算忽略了一个关键细节：Firebase Functions的CPU分配是和实例内存绑定的，默认实例是0.25 vCPU（也就是250 milliCPU）。配额里的CPU allocation in function invocations per 100 seconds是按CPU毫秒数计算的，不是你以为的CPU秒数，咱们重新算一遍：

1. 默认实例规格：0.25 vCPU = 250 milliCPU，意味着每个实例每秒会消耗250 CPU毫秒（1 vCPU秒 = 1000 milliCPU秒 = 1,000,000 CPU毫秒）。
2. 你的函数执行时长10秒，每个调用的CPU毫秒消耗是：250 milliCPU × 10秒 = 2500 CPU毫秒。
3. 你的配额是每100秒10万CPU毫秒，理论上每100秒最多支持的调用数是：100000 ÷ 2500 = 40次。

当100人测试时，短时间内并发调用超过了40次/100秒（比如达到50次），总CPU毫秒消耗就是50 × 2500 = 125000，直接超出10万限额，所以触发了429错误。

另外要注意：免费额度的4万GB·CPU秒是月度累计额度，但Cloud Functions同时有速率限制（比如per 100秒的配额），哪怕月度额度还剩很多，只要短时间内请求速率超过速率配额，一样会被限流。

二、Read Request与函数调用的区别 #

这是两个完全不同维度的配额，对应不同的资源操作：

• 函数调用（Function Invocation）：指触发Firebase Functions的请求次数，比如用户通过Hosting的Rewrite规则发送的/ecc请求，每一次请求就算一次函数调用。配额里的Function invocation per day、per 100 seconds都是限制这个触发次数。
• Read Request（存储读取请求）：指Cloud Storage的读取操作次数，比如你的函数转换PDF时，从Storage读取原始PDF文件，每读取一次就算一个Read Request。配额里的Read Request Per Day是限制每天从Storage读取文件的次数，和函数调用次数没有直接关联——一个函数调用可能触发多次Storage读取，也可能一次都不触发（比如本地处理时）。

一些优化建议 #

1. 调整实例规格：如果PDF转换不需要太高CPU性能，可尝试降低函数内存配置（比如从1GB降到512MB，对应CPU降到0.125 vCPU），减少每个调用的CPU毫秒消耗，从而支持更多并发；若需要更高性能，可升级到付费计划调整配额。
2. 优化函数执行时长：换用更高效的PDF转图片库（比如sharp搭配轻量PDF处理工具），减少每个调用的执行时间，降低CPU消耗。
3. 缓存结果：对已转换过的PDF，缓存生成的图片和SignedURL，避免重复转换，减少不必要的函数调用和Storage操作。
4. 查看详细监控：在Firebase控制台的Functions监控页面，查看每个调用的实际CPU使用时长、执行时间，确认计算与实际消耗是否匹配，找到优化点。

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