配額與限制

本頁面詳細說明 Cloud Functions 的可擴充用量限制 取決於 Blaze 即付即用定價方案。這些限制適用於 將函式部署至 Node.js 10 執行階段環境的 Firebase 專案。

Blaze 方案提供大量叫用、運算時間和 無須支付費用。不過，函式部署作業會產生小額費用，用於函式容器的儲存空間。詳情請參閱 Firebase 常見問題。

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

  • 資源限制

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

  • 時間限制

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

  • 頻率限制

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

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

資源限制

資源限制會影響函式可使用的資源總量。 區域範圍以專案為單位，且每項專案有各自的限制。

配額 說明 Limit (第 1 代) 限制 (第 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 否 每個函式
專案記憶體上限 計算範圍中，專案可使用的記憶體量。計算方式為 1 分鐘內，使用者要求的記憶體總和超過 1 分鐘。 視所選區域而定。在容量較高的地區，這個限制可能會提高；在最近開放的地區，則可能會降低。 不適用 是 每項專案和區域
專案 CPU 上限 專案可用的 CPU 量 (以千分之一 vCPU 為單位)。計算方式為 1 分鐘內，使用者要求的 CPU 總數 (針對所有函式執行個體) 的總和。 視所選區域而定。這個上限在高容量區域或最近開啟的區域可能較低。 不適用 是 每項專案和區域

時間限制

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

頻率限制

配額 說明 Limit (第 1 代) 限制 (第 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 參考資料。