Quản lý chức năng


Bạn có thể triển khai, xoá và sửa đổi các hàm bằng các lệnh CLI Firebase hoặc bằng cách đặt các tuỳ chọn thời gian chạy trong mã nguồn hàm.

Triển khai hàm

Để triển khai các hàm, hãy chạy lệnh CLI Firebase sau:

firebase deploy --only functions

Theo mặc định, CLI Firebase triển khai tất cả các hàm bên trong nguồn của bạn cùng một lúc. Nếu dự án của bạn chứa nhiều hơn 5 hàm, bạn nên sử dụng cờ --only với tên hàm cụ thể để chỉ triển khai các hàm mà bạn đã chỉnh sửa. Việc triển khai các hàm cụ thể theo cách này sẽ đẩy nhanh quá trình triển khai và giúp bạn tránh gặp phải hạn mức triển khai. Ví dụ:

firebase deploy --only functions:addMessage,functions:makeUppercase

Khi triển khai số lượng lớn hàm, bạn có thể vượt quá hạn mức chuẩn và nhận được thông báo lỗi HTTP 429 hoặc 500. Để giải quyết vấn đề này, hãy triển khai các hàm theo nhóm từ 10 trở xuống.

Hãy xem tài liệu tham khảo về CLI Firebase để biết danh sách đầy đủ các lệnh có sẵn.

Theo mặc định, CLI Firebase sẽ tìm mã nguồn trong thư mục functions/. Nếu muốn, bạn có thể sắp xếp các hàm trong cơ sở mã hoặc nhiều nhóm tệp.

Xoá hàm

Bạn có thể xoá các hàm đã triển khai trước đó theo những cách sau:

  • một cách rõ ràng trong CLI Firebase với functions:delete
  • rõ ràng trong bảng điều khiển Google Cloud.
  • ngầm ẩn bằng cách xoá hàm khỏi nguồn trước khi triển khai.

Mọi thao tác xoá đều nhắc bạn xác nhận trước khi xoá hàm khỏi phiên bản phát hành công khai.

Thao tác xoá hàm tường minh trong CLI Firebase hỗ trợ nhiều đối số cũng như các nhóm hàm và cho phép bạn chỉ định một hàm chạy trong một khu vực cụ thể. Ngoài ra, bạn có thể ghi đè lời nhắc xác nhận.

# Delete all functions that match the specified name in all regions.
firebase functions:delete myFunction

# Delete a specified function running in a specific region.
firebase functions:delete myFunction --region us-east-1

# Delete more than one function
firebase functions:delete myFunction myOtherFunction

# Delete a specified functions group.
firebase functions:delete groupA

# Bypass the confirmation prompt.
firebase functions:delete myFunction --force

Khi xoá hàm ngầm ẩn, firebase deploy sẽ phân tích cú pháp nguồn của bạn và xoá khỏi phiên bản chính thức mọi hàm đã bị xoá khỏi tệp.

Sửa đổi tên, vùng hoặc điều kiện kích hoạt của hàm

Nếu bạn đang đổi tên hoặc thay đổi các khu vực hoặc điều kiện kích hoạt cho các hàm đang xử lý lưu lượng truy cập công khai, hãy làm theo các bước trong phần này để tránh mất các sự kiện trong quá trình sửa đổi. Trước khi làm theo các bước này, trước tiên, hãy đảm bảo rằng hàm của bạn là không đổi, vì cả phiên bản mới và phiên bản cũ của hàm sẽ chạy cùng một lúc trong quá trình thay đổi.

Đổi tên hàm

Để đổi tên một hàm, hãy tạo một phiên bản mới được đổi tên của hàm đó trong nguồn rồi chạy hai lệnh triển khai riêng biệt. Lệnh đầu tiên triển khai hàm mới được đặt tên và lệnh thứ hai xoá phiên bản đã triển khai trước đó. Ví dụ: nếu bạn muốn đổi tên một webhook được HTTP kích hoạt, hãy sửa đổi mã như sau:

Node.js

// before
const {onRequest}  = require('firebase-functions/v2/https');

exports.webhook = onRequest((req, res) => {
    res.send("Hello");
});

// after
const {onRequest}  = require('firebase-functions/v2/https');

exports.webhookNew = onRequest((req, res) => {
    res.send("Hello");
});

Python

# before
from firebase_functions import https_fn

@https_fn.on_request()
def webhook(req: https_fn.Request) -> https_fn.Response:
    return https_fn.Response("Hello world!")

# after
from firebase_functions import https_fn

@https_fn.on_request()
def webhook_new(req: https_fn.Request) -> https_fn.Response:
    return https_fn.Response("Hello world!")

Sau đó, hãy chạy các lệnh sau để triển khai hàm mới:

# Deploy new function
firebase deploy --only functions:webhookNew

# Wait until deployment is done; now both functions are running

# Delete webhook
firebase functions:delete webhook

Thay đổi vùng miền hoặc các vùng miền của một hàm

Nếu đang thay đổi khu vực đã chỉ định cho một hàm đang xử lý lưu lượng truy cập chính thức, bạn có thể ngăn mất sự kiện bằng cách thực hiện lần lượt các bước sau:

  1. Đổi tên hàm và thay đổi vùng hoặc các vùng của hàm theo ý muốn.
  2. Triển khai hàm đã đổi tên, nhờ đó tạm thời chạy cùng một mã trong cả hai nhóm vùng.
  3. Xoá hàm trước đó.

Ví dụ: nếu bạn có một hàm được kích hoạt bằng Cloud Firestore hiện đang nằm trong vùng hàm mặc định của us-central1 và bạn muốn di chuyển hàm đó sang asia-northeast1, trước tiên, bạn cần sửa đổi mã nguồn để đổi tên hàm và sửa đổi vùng.

Node.js

// before
exports.firestoreTrigger = onDocumentCreated(
  "my-collection/{docId}",
  (event) => {},
);

// after
exports.firestoreTriggerAsia = onDocumentCreated(
  {
    document: "my-collection/{docId}",
    region: "asia-northeast1",
  },
  (event) => {},
);

Mã đã cập nhật phải chỉ định bộ lọc sự kiện chính xác (trong trường hợp này là document) cùng với khu vực. Hãy xem phần Vị trí của các hàm trên đám mây để biết thêm thông tin.

Python

# Before
@firestore_fn.on_document_created("my-collection/{docId}")
def firestore_trigger(event):
    pass

# After
@firestore_fn.on_document_created("my-collection/{docId}",
                                  region="asia-northeast1")
def firestore_trigger_asia(event):
    pass

Sau đó, hãy triển khai bằng cách chạy:

firebase deploy --only functions:firestoreTriggerAsia

Bây giờ, có hai hàm giống hệt nhau đang chạy: firestoreTrigger đang chạy trong us-central1 và firestoreTriggerAsia đang chạy trong asia-northeast1.

Sau đó, xoá firestoreTrigger:

firebase functions:delete firestoreTrigger

Hiện chỉ có một hàm là firestoreTriggerAsia, đang chạy trong asia-northeast1.

Thay đổi loại điều kiện kích hoạt của hàm

Khi phát triển quá trình triển khai Cloud Functions for Firebase theo thời gian, bạn có thể cần thay đổi loại trình kích hoạt của một hàm vì nhiều lý do. Ví dụ: bạn có thể muốn thay đổi từ một loại sự kiện Firebase Realtime Database hoặc Cloud Firestore sang một loại khác.

Bạn không thể thay đổi loại sự kiện của một hàm chỉ bằng cách thay đổi mã nguồn và chạy firebase deploy. Để tránh lỗi, hãy thay đổi loại trình kích hoạt của hàm theo quy trình sau:

  1. Sửa đổi mã nguồn để thêm một hàm mới có loại trình kích hoạt mong muốn.
  2. Triển khai hàm này để tạm thời chạy cả hàm cũ và hàm mới.
  3. Xoá rõ ràng hàm cũ khỏi phiên bản chính thức bằng cách sử dụng CLI Firebase.

Ví dụ: nếu bạn có một hàm được kích hoạt khi một đối tượng bị xoá, nhưng sau đó bạn đã bật tính năng phiên bản đối tượng và muốn đăng ký sự kiện lưu trữ, trước tiên, hãy đổi tên hàm và chỉnh sửa hàm đó để có loại trình kích hoạt mới.

Node.js

// before
const {onObjectDeleted} = require("firebase-functions/v2/storage");

exports.objectDeleted = onObjectDeleted((event) => {
    // ...
});

// after
const {onObjectArchived} = require("firebase-functions/v2/storage");

exports.objectArchived = onObjectArchived((event) => {
    // ...
});

Python

# before
from firebase_functions import storage_fn

@storage_fn.on_object_deleted()
def object_deleted(event):
  # ...

# after 
from firebase_functions import storage_fn

@storage_fn.on_object_archived()
def object_archived(event):
  # ...

Sau đó, hãy chạy các lệnh sau để tạo hàm mới trước khi xoá hàm cũ:

# Create new function objectArchived
firebase deploy --only functions:objectArchived

# Wait until deployment is done; now both objectDeleted and objectArchived are running

# Delete objectDeleted
firebase functions:delete objectDeleted

Đặt tuỳ chọn thời gian chạy

Cloud Functions for Firebase cho phép bạn chọn các tuỳ chọn thời gian chạy, chẳng hạn như phiên bản thời gian chạy Node.js và thời gian chờ cho mỗi hàm, mức phân bổ bộ nhớ và các thực thể hàm tối thiểu/tối đa.

Tốt nhất là bạn nên đặt các tuỳ chọn này (ngoại trừ phiên bản Node.js) trên một đối tượng cấu hình bên trong mã hàm. Đối tượng RuntimeOptions này là nguồn đáng tin cậy cho các tuỳ chọn thời gian chạy của hàm và sẽ ghi đè các tuỳ chọn được đặt thông qua bất kỳ phương thức nào khác (chẳng hạn như thông qua bảng điều khiển Google Cloud hoặc gcloud CLI).

Nếu quy trình phát triển của bạn liên quan đến việc đặt các tuỳ chọn thời gian chạy theo cách thủ công thông qua Google Cloud Console hoặc gcloud CLI và bạn không muốn các giá trị này bị ghi đè trên mỗi lần triển khai, hãy đặt tuỳ chọn preserveExternalChanges thành true. Khi bạn đặt tuỳ chọn này thành true, Firebase sẽ hợp nhất các tuỳ chọn thời gian chạy được đặt trong mã với chế độ cài đặt của phiên bản hàm đang được triển khai theo thứ tự ưu tiên sau:

  1. Tuỳ chọn được đặt trong mã hàm: ghi đè các thay đổi bên ngoài.
  2. Tuỳ chọn được đặt thành RESET_VALUE trong mã hàm: ghi đè các thay đổi bên ngoài bằng giá trị mặc định.
  3. Tuỳ chọn không được đặt trong mã hàm nhưng được đặt trong hàm hiện đã triển khai: sử dụng tuỳ chọn được chỉ định trong hàm đã triển khai.

Bạn không nên sử dụng tuỳ chọn preserveExternalChanges: true trong hầu hết các trường hợp vì mã của bạn sẽ không còn là nguồn đáng tin cậy đầy đủ cho các tuỳ chọn thời gian chạy của hàm. Nếu bạn sử dụng, hãy kiểm tra bảng điều khiển Google Cloud hoặc sử dụng gcloud CLI để xem cấu hình đầy đủ của một chức năng.

Đặt phiên bản Node.js

SDK Firebase cho Cloud Functions cho phép chọn thời gian chạy Node.js. Bạn có thể chọn chạy tất cả hàm trong một dự án chỉ trên môi trường thời gian chạy tương ứng với một trong các phiên bản Node.js được hỗ trợ sau:

  • Node.js 22 (bản xem trước)
  • Node.js 20
  • Node.js 18

Node.js Phiên bản 14 và 16 không còn được dùng nữa và sẽ ngừng hoạt động vào đầu năm 2025. Việc triển khai bằng các phiên bản không dùng nữa này sẽ bị tắt.

Cách đặt phiên bản Node.js:

Bạn có thể đặt phiên bản trong trường engines trong tệp package.json được tạo trong thư mục functions/ trong quá trình khởi chạy. Ví dụ: để chỉ sử dụng phiên bản 18, hãy chỉnh sửa dòng này trong package.json:

  "engines": {"node": "20"}

Nếu đang sử dụng trình quản lý gói Yarn hoặc có các yêu cầu cụ thể khác đối với trường engines, thì bạn có thể đặt thời gian chạy cho SDK Firebase cho Cloud Functions trong firebase.json:

  {
    "functions": {
      "runtime": "nodejs18" // or nodejs20
    }
  }

CLI sử dụng giá trị được đặt trong firebase.json thay vì bất kỳ giá trị hoặc phạm vi nào mà bạn đặt riêng trong package.json.

Nâng cấp thời gian chạy Node.js

Cách nâng cấp môi trường thời gian chạy Node.js:

  1. Đảm bảo dự án của bạn đang sử dụng gói giá Blaze.
  2. Đảm bảo bạn đang sử dụng Firebase CLI phiên bản 11.18.0 trở lên.
  3. Thay đổi giá trị engines trong tệp package.json được tạo trong thư mục functions/ trong quá trình khởi chạy. Ví dụ: nếu bạn đang nâng cấp từ phiên bản 18 lên phiên bản 20, mục nhập sẽ có dạng như sau: "engines": {"node": "20"}
  4. Bạn có thể kiểm thử các thay đổi bằng Firebase Local Emulator Suite.
  5. Triển khai lại tất cả các hàm.

Đặt phiên bản Python

SDK Firebase dành cho Cloud Functions phiên bản 12.0.0 trở lên cho phép lựa chọn thời gian chạy Python. Đặt phiên bản thời gian chạy trong firebase.json như sau:

  {
    "functions": {
      "runtime": "python310" // or python311
    }
  }

Kiểm soát hành vi điều chỉnh theo tỷ lệ

Theo mặc định, Cloud Functions for Firebase điều chỉnh số lượng thực thể đang chạy dựa trên số lượng yêu cầu đến, có thể điều chỉnh xuống 0 thực thể trong thời gian lưu lượng truy cập giảm. Tuy nhiên, nếu ứng dụng của bạn yêu cầu độ trễ giảm và bạn muốn giới hạn số lần khởi động nguội, thì bạn có thể thay đổi hành vi mặc định này bằng cách chỉ định số lượng thực thể vùng chứa tối thiểu được giữ ấm và sẵn sàng phân phát các yêu cầu.

Tương tự, bạn có thể đặt số lượng tối đa để giới hạn việc mở rộng quy mô của các thực thể nhằm phản hồi các yêu cầu sắp tới. Sử dụng chế độ cài đặt này để kiểm soát chi phí hoặc giới hạn số lượng kết nối với một dịch vụ sao lưu, chẳng hạn như với cơ sở dữ liệu.

Khi sử dụng các chế độ cài đặt này cùng với chế độ cài đặt đồng thời trên mỗi thực thể (mới trong phiên bản thứ 2), bạn có thể kiểm soát và điều chỉnh hành vi điều chỉnh theo tỷ lệ cho các hàm của mình. Bản chất của ứng dụng và hàm sẽ xác định chế độ cài đặt nào hiệu quả nhất về chi phí và mang lại hiệu suất tốt nhất.

Đối với một số ứng dụng có lưu lượng truy cập thấp, bạn nên chọn CPU thấp hơn mà không cần nhiều luồng đồng thời. Đối với những thực thể khác mà quy trình khởi động nguội là vấn đề nghiêm trọng, việc đặt tính đồng thời cao và thực thể tối thiểu có nghĩa là một tập hợp các thực thể luôn được giữ ấm để xử lý các mức tăng đột biến lớn trong lưu lượng truy cập.

Đối với các ứng dụng có quy mô nhỏ nhận được rất ít lưu lượng truy cập, việc đặt số lượng thực thể tối đa thấp với mức đồng thời cao có nghĩa là ứng dụng có thể xử lý các đợt lưu lượng truy cập mà không phải chịu chi phí quá mức. Tuy nhiên, hãy lưu ý rằng khi bạn đặt số lượng thực thể tối đa quá thấp, các yêu cầu có thể bị loại bỏ khi đạt đến hạn mức.

Cho phép yêu cầu đồng thời

Trong Cloud Functions for Firebase (thế hệ 1), mỗi thực thể có thể xử lý một yêu cầu tại một thời điểm, vì vậy, hành vi điều chỉnh theo tỷ lệ chỉ được đặt bằng chế độ cài đặt thực thể tối thiểu và tối đa. Ngoài việc kiểm soát số lượng thực thể, trong Cloud Functions for Firebase (thế hệ thứ 2), bạn có thể kiểm soát số lượng yêu cầu mà mỗi thực thể có thể phân phát cùng lúc bằng tuỳ chọn concurrency. Giá trị mặc định cho tính năng đồng thời là 80, nhưng bạn có thể đặt giá trị này thành bất kỳ số nguyên nào từ 1 đến 1000.

Các hàm có chế độ cài đặt đồng thời cao hơn có thể hấp thụ lưu lượng truy cập tăng đột biến mà không cần khởi động nguội vì mỗi thực thể có thể có một mức trần. Nếu một thực thể được định cấu hình để xử lý tối đa 50 yêu cầu đồng thời nhưng hiện chỉ xử lý 25 yêu cầu, thì thực thể đó có thể xử lý trường hợp tăng đột biến 25 yêu cầu bổ sung mà không cần có phiên bản mới để khởi động nguội. Ngược lại, với chế độ cài đặt đồng thời chỉ là 1, sự gia tăng đột biến về số lượng yêu cầu đó có thể dẫn đến 25 lần khởi động nguội.

Tình huống đơn giản này minh hoạ mức tăng hiệu quả tiềm năng của tính đồng thời. Trong thực tế, hành vi mở rộng quy mô để tối ưu hoá hiệu quả và giảm số lần khởi động nguội bằng tính năng đồng thời phức tạp hơn. Tính năng đồng thời trong Cloud Functions for Firebase thế hệ thứ 2 do Cloud Run cung cấp và tuân theo các quy tắc của Cloud Run về tự động cấp tài nguyên bổ sung cho thực thể vùng chứa.

Khi thử nghiệm các chế độ cài đặt đồng thời cao hơn trong Cloud Functions for Firebase (thế hệ thứ 2), hãy lưu ý những điều sau:

  • Chế độ cài đặt đồng thời cao hơn có thể yêu cầu CPU và RAM cao hơn để đạt được hiệu suất tối ưu cho đến khi đạt đến giới hạn thực tế. Ví dụ: một hàm xử lý nhiều hình ảnh hoặc video có thể thiếu tài nguyên để xử lý 1.000 yêu cầu đồng thời, ngay cả khi chế độ cài đặt CPU và RAM của hàm đó được tối đa hoá.
  • Vì Cloud Functions for Firebase (thế hệ thứ 2) do Cloud Run cung cấp, bạn cũng có thể tham khảo hướng dẫn về Google Cloud để tối ưu hoá mô hình đồng thời.
  • Hãy nhớ kiểm thử kỹ lưỡng tính năng đa luồng trong môi trường thử nghiệm trước khi chuyển sang tính năng đa luồng trong môi trường sản xuất.

Giữ ấm số lượng thực thể tối thiểu

Bạn có thể đặt số lượng thực thể tối thiểu cho một hàm trong mã nguồn. Ví dụ: hàm này đặt tối thiểu 5 thực thể để giữ ấm:

Node.js

const { onCall } = require("firebase-functions/v2/https");

exports.getAutocompleteResponse = onCall(
  {
    // Keep 5 instances warm for this latency-critical function
    minInstances: 5,
  },
  (event) => {
    // Autocomplete user’s search term
  }
);

Python

@https_fn.on_call(min_instances=5)
def get_autocomplete_response(event: https_fn.CallableRequest) -> https_fn.Response:

Dưới đây là một số điều cần xem xét khi đặt giá trị số thực thể tối thiểu:

  • Nếu Cloud Functions for Firebase mở rộng ứng dụng của bạn vượt quá chế độ cài đặt, bạn sẽ thấy trạng thái khởi động nguội cho mỗi thực thể vượt quá ngưỡng đó.
  • Khởi động nguội ảnh hưởng nghiêm trọng nhất đến những ứng dụng có lưu lượng truy cập tăng đột biến. Nếu ứng dụng của bạn có lưu lượng truy cập tăng đột biến và bạn đặt giá trị đủ cao để giảm số lần khởi động nguội trên mỗi lần lưu lượng truy cập tăng, thì bạn sẽ thấy độ trễ giảm đáng kể. Đối với các ứng dụng có lưu lượng truy cập không đổi, việc khởi động nguội có thể sẽ không ảnh hưởng nghiêm trọng đến hiệu suất.

  • Việc đặt các thực thể tối thiểu có thể phù hợp với môi trường phát hành chính thức, nhưng thường nên tránh trong môi trường kiểm thử. Để mở rộng quy mô về 0 trong dự án kiểm thử nhưng vẫn giảm thiểu số lần khởi động nguội trong dự án phát hành công khai, bạn có thể đặt giá trị thực thể tối thiểu trong cấu hình có tham số:

    Node.js

    const functions = require('firebase-functions/v1');
const { defineInt, defineString } = require('firebase-functions/params');

// Define some parameters
const minInstancesConfig = defineInt('HELLO_WORLD_MININSTANCES');
const welcomeMessage = defineString('WELCOME_MESSAGE');

// To use configured parameters inside the config for a function, provide them 
// directly. To use them at runtime, call .value() on them.
export const helloWorld = functions.runWith({ minInstances: minInstancesConfig}).https.onRequest(
  (req, res) => {
    res.send(`${welcomeMessage.value()}! I am a function.`);
  }
);

    Python

    MIN_INSTANCES = params.IntParam("HELLO_WORLD_MININSTANCES")
WELCOME_MESSAGE = params.StringParam("WELCOME_MESSAGE")

@https_fn.on_request(min_instances=MIN_INSTANCES.value())
def get_autocomplete_response(event: https_fn.Request) -> https_fn.Response:
    return https_fn.Response(f"{WELCOME_MESSAGE.value()} I'm a function.")

Giới hạn số lượng thực thể tối đa cho một hàm

Bạn có thể đặt giá trị cho số thực thể tối đa trong mã nguồn của hàm. Ví dụ: hàm này đặt giới hạn 100 thực thể để không gây choáng ngợp cơ sở dữ liệu cũ giả định:

Node.js

const { onMessagePublished } = require("firebase-functions/v2/pubsub");

exports.mirrorevents = onMessagePublished(
  { topic: "topic-name", maxInstances: 100 },
  (event) => {
    // Connect to legacy database
  }
);

Python

@pubsub_fn.on_message_published(topic="topic-name", max_instances=100)
def mirrorevents(event: pubsub_fn.CloudEvent):
#  Connect to legacy database

Nếu một hàm HTTP được mở rộng đến giới hạn số thực thể tối đa, thì các yêu cầu mới sẽ được thêm vào hàng đợi trong 30 giây, sau đó bị từ chối bằng mã phản hồi 429 Too Many Requests nếu không có thực thể nào sau đó.

Để tìm hiểu thêm về các phương pháp hay nhất để sử dụng chế độ cài đặt số lượng thực thể tối đa, hãy xem các phương pháp hay nhất để thiết lập số lượng thực thể tối đa.

Đặt thời gian chờ và phân bổ bộ nhớ

Trong một số trường hợp, các hàm của bạn có thể có các yêu cầu đặc biệt đối với giá trị thời gian chờ dài hoặc mức phân bổ bộ nhớ lớn. Bạn có thể đặt các giá trị này trong bảng điều khiển Google Cloud hoặc trong mã nguồn hàm (chỉ Firebase).

Để thiết lập quy trình phân bổ bộ nhớ và thời gian chờ trong mã nguồn của các hàm, hãy sử dụng các tuỳ chọn chung cho bộ nhớ và thời gian chờ theo giây để tuỳ chỉnh máy ảo đang chạy các hàm của bạn. Ví dụ: hàm Cloud Storage này sử dụng 1GiB bộ nhớ và hết thời gian chờ sau 300 giây:

Node.js

exports.convertLargeFile = onObjectFinalized({
  timeoutSeconds: 300,
  memory: "1GiB",
}, (event) => {
  // Do some complicated things that take a lot of memory and time
});

Python

@storage_fn.on_object_finalized(timeout_sec=300, memory=options.MemoryOption.GB_1)
def convert_large_file(event: storage_fn.CloudEvent):
# Do some complicated things that take a lot of memory and time.

Giá trị tối đa cho số giây chờ là 540, tức là 9 phút.

Cách thiết lập quy trình phân bổ bộ nhớ và thời gian chờ trong bảng điều khiển Google Cloud:

  1. Trong bảng điều khiển Google Cloud, hãy chọn Cloud Functions for Firebase trong trình đơn bên trái.
  2. Chọn một hàm bằng cách nhấp vào tên hàm đó trong danh sách hàm.
  3. Nhấp vào biểu tượng Chỉnh sửa trong trình đơn trên cùng.
  4. Chọn một mức phân bổ bộ nhớ trong trình đơn thả xuống có nhãn Memory allocated (Bộ nhớ được phân bổ).
  5. Nhấp vào Thêm để hiển thị các tuỳ chọn nâng cao, rồi nhập số giây vào hộp văn bản Timeout (Hết thời gian chờ).
  6. Nhấp vào Lưu để cập nhật hàm.

Ghi đè các giá trị mặc định của CPU

Bộ nhớ được phân bổ tối đa 2GB, mỗi hàm trong Cloud Functions for Firebase (thế hệ 2) mặc định là một CPU, sau đó tăng lên 2 CPU cho 4 và 8GB. Xin lưu ý rằng hành vi này khác biệt đáng kể so với hành vi mặc định của thế hệ 1 theo những cách có thể dẫn đến chi phí cao hơn một chút đối với các hàm có bộ nhớ thấp như thể hiện trong bảng sau:

RAM được phân bổ CPU mặc định của phiên bản 1 (phân số) CPU mặc định phiên bản 2 Mức tăng giá mỗi mili giây
128 MB 1/12 1 10,5 lần
256MB 1/6 1 5,3x
512MB 1/3 1 2,7x
1 GB 12/7 1 1,6 lần
2 GB 1 1 1x
4 GB 2 2 1x
8 GB 2 2 1x
16 GB không có 4 không có

Nếu bạn muốn sử dụng hành vi của thế hệ 1 cho các hàm thế hệ 2, hãy đặt giá trị mặc định của thế hệ 1 làm tuỳ chọn chung:

Node.js

// Turn off Firebase defaults
setGlobalOptions({ cpu: 'gcf_gen1' });

Python

# Use 1st gen behavior
set_global_options(cpu="gcf_gen1")

Đối với các hàm sử dụng nhiều CPU, thế hệ thứ 2 mang lại khả năng linh hoạt để định cấu hình thêm CPU. Bạn có thể tăng tốc CPU trên cơ sở từng hàm như sau:

Node.js

// Boost CPU in a function:
export const analyzeImage = onObjectFinalized({ cpu: 2 }, (event) => {
  // computer vision goes here
});

Python

# Boost CPU in a function:
@storage_fn.on_object_finalized(cpu=2)
def analyze_image(event: storage_fn.CloudEvent):
# computer vision goes here