本頁面詳細說明Cloud Functions的用量限制，這些限制會根據即付即用 Blaze 定價方案調整。這些限制適用於將函式部署至 Node.js 10 執行階段環境的 Firebase 專案。
Blaze 定價方案提供大量免費的叫用次數、運算時間和網際網路流量。不過，函式部署會產生小額費用，用於支付函式容器使用的儲存空間。詳情請參閱常見問題。
「Cloud Functions」的配額包含 4 個方面：
資源限制
這些配額限制會影響函式可使用的總資源量。
時間限制
這些配額限制會影響作業執行時間。
頻率限制
這類限制會影響您可呼叫 Cloud Functions API 來管理函式的頻率。
網路限制
這類限制會影響傳出連線和執行個體的數量上限。
以下將詳細說明各類限制。如果 Cloud Functions (第 1 代) 和 Cloud Functions (第 2 代) 的限制有所不同，我們註明相關資訊。
資源限制
資源限制會影響函式可使用的總資源量。區域範圍以專案為單位，每個專案有各自的限制。
| 配額 | 說明 | 限制 (第 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。 |
否 | 每個事件 |
| 函式記憶體用量上限 | 每個函式執行個體可用的記憶體量 | 8 GiB | 32 GiB | 否 | 每個函式 |
| 專案記憶體用量上限 | 專案可用的記憶體量 (以位元組為單位)，計算方式是加總各函式執行個體在 1 分鐘內，依使用者要求的記憶體總數。 | 視所選區域而定。高容量區域的上限可能較高，近期開放區域的上限可能較低。 | 不適用 | 是 | 每個專案和區域 |
| 專案 CPU 用量上限 | 專案可用的 CPU 數量 (以 m vCPU 為單位)，計算方式是加總各函式執行個體在 1 分鐘內，依使用者要求的 CPU 總數。 | 視所選區域而定。高容量區域的上限可能較高，近期開放區域的上限可能較低。 | 不適用 | 是 | 每個專案和區域 |
時間限制
| 配額 | 說明 | 限制 (第 1 代) | 限制 (第 2 代) | 能否增加 | 範圍 |
|---|---|---|---|---|---|
| 函式持續時間上限 | 函式最多可執行多長時間，超過上限即會強制終止 | 540 秒 |
|
否 | 每次叫用 |
頻率限制
| 配額 | 說明 | 限制 (第 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) | 呼叫「call」API 的次數 | 每 100 秒 16 次 | 不適用 | 否2 | 每項專案 |
網路限制
如要瞭解 Cloud Functions (第 2 代) 的網路要求和頻寬限制，請參閱「網路限制」。
下列網路限制適用於 Cloud Functions (第 1 代)：
- 每個執行個體每秒的傳出連線數：500 (無法增加)
- 每個執行個體每秒的傳出 DNS 解析次數：100 (無法增加)
- 每個執行個體每秒封包數上限：80,000
- 每個執行個體每秒位元數上限：100,000,000
擴充性
透過 HTTP 叫用的 Cloud Functions 會迅速擴充運算能力來處理傳入的流量，背景函式擴充的速度則較慢。函式的擴充能力取決於幾個因素，包括：
- 函式執行作業完成所需的時間。一般來說，執行時間較短的函式可以擴充運算能力，以處理更多並行要求。
- 函式在冷啟動下初始化所需的時間。
- 函式的錯誤率。
暫時性因素，例如區域性負載和資料中心運算資源。
背景函式的額外配額
| 配額 | 說明 | 限制 | 是否可增加 | 範圍 | 產品版本 |
|---|---|---|---|---|---|
| 並行叫用次數上限 | 單一函式的並行叫用次數上限 例如：如果處理每個事件需要 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 配額頁面，選取要修改的配額項目，接著點選「Edit quotas」(編輯配額)，再分別輸入所選各項配額的新上限。系統可能會要求您提供使用者資訊，請按照提示操作。
Firebase CLI 部署作業的配額限制
Firebase CLI 部署的每個函式都會受到下列速率和時間限制影響：
- API 呼叫次數 (讀取) - 每次部署 1 次呼叫，無論函式數量為何
- 上限：每 100 秒 5,000 次
- API 呼叫次數 (寫入) - 每個函式 1 次呼叫
- 上限：每 100 秒 80 次
另請參閱 Firebase CLI 參考資料。