配額與限制

本頁面詳細說明 Cloud Functions 的彈性用量限制,並依據 Blaze 即付即用定價方案計算。這些限制適用於將函式部署至 Node.js 10 執行階段環境的 Firebase 專案。

Blaze 方案提供充足的叫用次數、運算時間和網際網路流量,且免付費用。不過,函式部署作業會產生小額費用,用於函式容器的儲存空間。詳情請參閱 Firebase 常見問題

Google Cloud Functions 的配額包含 3 個方面:

  • 資源限制

    這些配額限制會影響函式可使用的總資源量。

  • 時間限制

    這些配額限制會影響作業執行時間。

  • 頻率限制

    這些配額會影響您可以呼叫 Cloud Functions API 的頻率 來管理函式

下表將詳細說明各類限制。在適用情況下,我們會指出 Cloud Functions (第 1 代) 和 Cloud Functions (第 2 代) 的限制差異。

資源限制

資源限制會影響函式可使用的資源總量。 區域範圍是專案層級,每個專案都有各自的限制。

配額 說明 限制 (第 1 代) Limit (第 2 代) 是否可增加 範圍
函式數量 每個區域可部署的函式總數 1,000 1,000 減去已部署的 Cloud Run 服務數量 每個區域
部署作業大小上限 單一函式部署作業的大小上限 來源為 100 MB (經過壓縮)。
來源加模組為 500 MB (未經壓縮)。
不適用 每個函式
未壓縮的 HTTP 要求大小上限 在一項 HTTP 要求中,傳送至 HTTP 函式的資料量 10 MB 32 MB 每次叫用
未壓縮的 HTTP 回應大小上限 在一項 HTTP 回應中,HTTP 函式傳出的資料量 10 MB 串流回應為 10 MB。
32 MB 非串流回應。
每次叫用
事件導向函式的事件大小上限 在事件中傳送至背景函式的資料量 10 MB Eventarc 事件:512 KB。
針對舊版事件為 10 MB。
每個事件
函式記憶體用量上限 每個函式執行個體可用的記憶體量 8GiB 32GiB 每個函式
專案記憶體上限 專案可使用的記憶體量,以 By 為單位。這項指標的計算方式是,在 1 分鐘內,函式執行個體中使用者要求的記憶體總和。 取決於所選區域。這個上限在高容量區域或最近開啟的區域可能較低。 不適用 每個專案和區域
專案 CPU 上限 專案可使用的 CPU 數量 (以毫秒 vCPU 為單位)。計算方式為在 1 分鐘內,函式執行個體中使用者要求的 CPU 總和。 視所選區域而定。在容量較高的地區,這個限制可能會提高;在最近開放的地區,則可能會降低。 不適用 每個專案和區域

時間限制

配額 說明 限制 (第 1 代) Limit (第 2 代) 是否可增加 範圍
函式持續時間上限 函式可執行的時間長度上限,一旦超過時限即會遭強制終止 540 秒 HTTP 函式為 60 分鐘。
事件導向函式為 9 分鐘。
每次叫用

頻率限制

配額 說明 限制 (第 1 代) Limit (第 2 代) 是否可增加 範圍
API 呼叫次數 (讀取) 透過 Cloud Functions API 描述或列出函式的呼叫次數。 每 100 秒 5,000 次 每 60 秒 1,200 次 僅適用於第 1 代 每個專案 (第 1 代)
每個區域 (第 2 代)
API 呼叫次數 (寫入) 透過 Cloud Functions API 部署或刪除函式的呼叫次數。 每 100 秒 80 次 每 60 秒 60 次 1 每項專案 (第 1 代)
每個區域 (第 2 代)
API 呼叫次數 (呼叫) 呼叫「call」API 的次數 每 100 秒 16 次 不適用 2 每項專案

擴充性

透過 HTTP 叫用的 Cloud Functions 會迅速擴充運算能力來處理傳入的流量,背景函式擴充的速度則較慢。函式的擴充能力取決於幾個因素,包括:

  • 函式執行作業完成所需的時間。一般來說,執行時間較短的函式可以擴充運算能力,以處理更多並行要求。
  • 函式在冷啟動情況下初始化所需的時間。
  • 函式的錯誤率。
  • 暫時性因素,例如區域負載和資料中心的運算資源。

背景函式有 這些限制不適用於第 1 代 HTTP 函式

背景函式的額外配額

配額 說明 限制 是否可增加 範圍 產品版本
並行叫用次數上限 單一函式的並行叫用次數上限
例如:如果處理每個事件需要 100 秒,則平均叫用頻率上限為每秒 30 次
3,000 每個函式 僅限第 1 代
叫用頻率上限 單一函式處理事件的頻率上限
例如:如果處理一個事件需要 100 毫秒,即使平均只需同時處理 100 個要求,叫用頻率上限仍為每秒 1,000 次
每秒 1,000 次 每個函式 僅限第 1 代
並行事件資料大小上限 並行叫用單一函式的連入事件總大小上限
例如:假設事件大小均為 1 MB,且處理它們需要 10 秒,則平均頻率為每秒 1 個事件。因為系統必須等到前 10 個事件中的任一事件處理完畢後,才會開始處理第 11 個事件
10 MB 每個函式 第 1 代和第 2 代
連入事件的總處理量上限 單一函式連入事件的總處理量上限
例如:如果事件大小為 1 MB,則叫用頻率上限為每秒 10 次 (即使函式可在 100 毫秒內完成也一樣)
每秒 10 MB 每個函式 第 1 代和第 2 代

達到配額限制後會出現什麼情況

如果特定函式耗盡了系統分配的某項資源,那麼在配額獲得補充或增加前,此項資源都無法再使用。這段期間內,該函式和同一項專案中的所有其他函式可能無法正常運作。如果某項資源超過配額並導致函式無法正常運作,該函式會傳回 HTTP 500 錯誤代碼。

如果需要的配額超過本頁所列的預設值,您可以要求增加配額,方法是前往 Cloud Functions 配額頁面選取要修改的配額項目,接著按一下 [編輯配額],然後針對您選取的各項配額輸入新的上限。系統可能會要求您提供使用者資訊,這時請按照提示訊息中的指示操作。

Firebase CLI 部署作業的配額限制

對於 Firebase CLI 部署的每個函式,以下類型的頻率和時間限制都會受到影響:

  • API 呼叫 (讀取) - 每個部署 1 次呼叫 (無論函式數量為何)
    • 上限:每 100 秒 5,000 次
  • API 呼叫次數 (寫入) - 每個函式 1 次呼叫
    • 限制:每 100 秒 80 次

另請參閱 Firebase CLI 參考資料