Bạn có thể triển khai, xoá và sửa đổi các hàm bằng cách sử dụng các lệnh CLI Firebase hoặc bằng cách thiết lập các lựa 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 sẽ triển khai tất cả các hàm trong nguồn của bạn cùng một lúc. Nếu dự án của bạn có 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 những hàm mà bạn đã chỉnh sửa. 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 tiêu 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 gồm tối đa 10 hàm.
Hãy xem Firebase tài liệu tham khảo về CLI để biết danh sách đầy đủ các lệnh có sẵn.
Theo mặc định, giao diện dòng lệ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.
Dọn dẹp các cấu phần phần mềm triển khai
Trong quá trình triển khai hàm, các hình ảnh vùng chứa sẽ được tạo và lưu trữ trong Artifact Registry. Các hàm đã triển khai không bắt buộc phải có những hình ảnh này để chạy; Cloud Functions sẽ tìm nạp và giữ lại một bản sao của hình ảnh trong quá trình triển khai ban đầu, nhưng các cấu phần phần mềm được lưu trữ không cần thiết để hàm hoạt động trong thời gian chạy.
Mặc dù các hình ảnh vùng chứa này thường có kích thước nhỏ, nhưng chúng có thể tích luỹ theo thời gian và làm tăng chi phí lưu trữ của bạn. Bạn có thể muốn giữ lại các tệp này trong một khoảng thời gian nếu dự định kiểm tra các cấu phần phần mềm đã tạo hoặc chạy quét lỗ hổng bảo mật của vùng chứa.
Để giúp quản lý chi phí lưu trữ, Firebase CLI 14.0.0 trở lên cho phép bạn định cấu hình Artifact Registry chính sách dọn dẹp cho các kho lưu trữ lưu trữ cấu phần phần mềm triển khai sau mỗi lần triển khai hàm.
Bạn có thể thiết lập hoặc chỉnh sửa chính sách dọn dẹp theo cách thủ công bằng lệnh functions:artifacts:setpolicy
:
firebase functions:artifacts:setpolicy
Theo mặc định, lệnh này sẽ định cấu hình Artifact Registry để tự động xoá các hình ảnh vùng chứa cũ hơn 1 ngày. Điều này giúp cân bằng hợp lý giữa việc giảm thiểu chi phí lưu trữ và cho phép kiểm tra các bản dựng gần đây.
Bạn có thể tuỳ chỉnh khoảng thời gian lưu giữ bằng cách sử dụng tuỳ chọn --days
:
firebase functions:artifacts:setpolicy --days 7 # Delete images older than 7 days
Nếu triển khai các hàm cho nhiều khu vực, bạn có thể thiết lập một chính sách dọn dẹp cho một vị trí cụ thể bằng cách sử dụng lựa chọn --location
:
$ firebase functions:artifacts:setpolicy --location europe-west1
Chọn không dọn dẹp cấu phần phần mềm
Nếu muốn quản lý việc dọn dẹp hình ảnh theo cách thủ công hoặc nếu không muốn xoá bất kỳ hình ảnh nào, bạn có thể chọn không sử dụng hoàn toàn các chính sách dọn dẹp:
$ firebase functions:artifacts:setpolicy --none
Lệnh này sẽ xoá mọi chính sách dọn dẹp hiện có mà CLI Firebase đã thiết lập và ngăn Firebase thiết lập chính sách dọn dẹp sau khi triển khai hàm.
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 bằng
functions:delete
- một cách rõ ràng trong bảng điều khiển Google Cloud.
- một cách gián tiếp bằng cách xoá hàm khỏi nguồn trước khi triển khai.
Tất cả các thao tác xoá đều nhắc bạn xác nhận trước khi xoá chức năng khỏi phiên bản phát hành công khai.
Lệnh xoá hàm rõ ràng 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 đang chạy ở một khu vực cụ thể. Ngoài ra, bạn có thể bỏ qua 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
Với tính năng xoá hàm ngầm ẩn, firebase deploy
sẽ phân tích cú pháp nguồn của bạn và xoá mọi hàm đã bị xoá khỏi tệp khỏi bản phát hành chính thức.
Sửa đổi tên, khu vực hoặc điều kiện kích hoạt của một hàm
Nếu bạn đang đổi tên hoặc thay đổi 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 thực tế, hãy làm theo các bước trong phần này để tránh mất 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à đẳng phương, vì cả phiên bản mới và phiên bản cũ của hàm sẽ chạy cùng 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 đã đổi tên của hàm đó trong nguồn của bạn, sau đó chạy 2 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 có một webhook được kích hoạt bằng HTTP mà bạn muốn đổi tên, hãy sửa đổi mã như sau:
// 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");
});
# 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 khu vực hoặc các khu vực của một hàm
Nếu đang thay đổi khu vực được chỉ định cho một hàm đang xử lý lưu lượng truy cập sản xuất, bạn có thể ngăn chặn tình trạng mất sự kiện bằng cách thực hiện các bước sau theo thứ tự:
- Đổi tên hàm và thay đổi (các) vùng của hàm theo ý muốn.
- Triển khai hàm được đổi tên, dẫn đến việc tạm thời chạy cùng một mã trong cả hai nhóm khu vực.
- Xoá hàm trước đó.
Ví dụ: nếu có một hàm do Cloud Firestore kích hoạt hiện đang ở 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
, thì 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.
// 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 các vị trí của Cloud Functions để biết thêm thông tin.
# 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 đó, triển khai bằng cách chạy:
firebase deploy --only functions:firestoreTriggerAsia
Giờ đây, có 2 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 đó, hãy xoá firestoreTrigger
:
firebase functions:delete firestoreTrigger
Giờ đây, chỉ có một hàm là firestoreTriggerAsia
, đang chạy trong asia-northeast1
.
Thay đổi loại trình kích hoạt của hàm
Khi phát triển việc 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ừ loại sự kiện Firebase Realtime Database hoặc Cloud Firestore này sang loại sự kiện 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 điều kiện kích hoạt của hàm theo quy trình này:
- 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.
- Triển khai hàm, dẫn đến việc tạm thời chạy cả hàm cũ và hàm mới.
- Xoá rõ ràng hàm cũ khỏi quy trình sản xuất 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 quản lý 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.
// before
const {onObjectDeleted} = require("firebase-functions/v2/storage");
exports.objectDeleted = onObjectDeleted((event) => {
// ...
});
// after
const {onObjectArchived} = require("firebase-functions/v2/storage");
exports.objectArchived = onObjectArchived((event) => {
// ...
});
# 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 các lựa chọn về 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 như phiên bản thời gian chạy Node.js và thời gian chờ theo từng hàm, việc phân bổ bộ nhớ và số lượng phiên bản hàm tối thiểu/tối đa.
Theo phương pháp hay nhất, bạn nên đặt các lựa 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 lựa chọn thời gian chạy của hàm và sẽ ghi đè các lựa 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 giao diện dòng lệnh gcloud).
Nếu quy trình phát triển của bạn liên quan đến việc thiết lập các lựa chọn thời gian chạy theo cách thủ công thông qua bảng điều khiển Google Cloud 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 lựa 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ã của bạn với chế độ cài đặt của phiên bản hàm hiện đang triển khai theo mức độ ưu tiên sau:
- Lựa chọn được đặt trong mã hàm: ghi đè các thay đổi bên ngoài.
- Lựa 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. - Lựa chọn không được đặt trong mã hàm, nhưng được đặt trong hàm hiện đang được triển khai: sử dụng lựa chọn được chỉ định trong hàm đã triển khai.
Bạn không nên sử dụng lựa chọn preserveExternalChanges: true
cho hầu hết các trường hợp vì mã của bạn sẽ không còn là nguồn thông tin đầy đủ về các lựa chọn thời gian chạy cho các hàm của bạn. Nếu bạn sử dụng công cụ này, hãy kiểm tra bảng điều khiển Google Cloud hoặc sử dụng CLI gcloud để xem toàn bộ cấu hình của một hàm.
Đặt phiên bản Node.js
Firebase SDK 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ả cá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 đây:
- Node.js 22
- Node.js 20
- Node.js 18 (không dùng nữa)
Node.js phiên bản 14 và 16 đã ngừng hoạt động vào đầu năm 2025. Không thể triển khai bằng các phiên bản này. Hãy xem lịch hỗ trợ để biết thông tin quan trọng về việc tiếp tục hỗ trợ các phiên bản Node.js này.
Cách thiết lập 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 20, 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 cho trường engines
, bạn có thể đặt thời gian chạy cho SDK Firebase cho Cloud Functions trong firebase.json
thay vì:
{
"functions": {
"runtime": "nodejs20" // or nodejs22
}
}
CLI sẽ ưu tiên sử dụng giá trị được đặt trong firebase.json
thay vì bất kỳ giá trị hoặc dải giá trị 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 thời gian chạy Node.js:
- Đảm bảo dự án của bạn sử dụng Gói giá linh hoạt.
- Đảm bảo bạn đang sử dụng Firebase CLI phiên bản 11.18.0 trở lên.
- Thay đổi giá trị
engines
trong tệppackage.json
được tạo trong thư mụcfunctions/
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, thì mục nhập sẽ có dạng như sau:"engines": {"node": "20"}
- Nếu muốn, bạn có thể kiểm thử các thay đổi bằng Firebase Local Emulator Suite.
- Triển khai lại tất cả các hàm.
Đặt phiên bản Python
SDK Firebase cho Cloud Functions phiên bản 12.0.0 trở lên cho phép chọn thời gian chạy Python. Đặt phiên bản thời gian chạy trong firebase.json
như minh hoạ:
{
"functions": {
"runtime": "python310" // or python311
}
}
Kiểm soát hành vi điều chỉnh tỷ lệ
Theo mặc định, Cloud Functions for Firebase sẽ điều chỉnh quy mô số lượng thực thể đang chạy dựa trên số lượng yêu cầu đến, có thể giảm 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 giảm độ trễ 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 tối thiểu các phiên bản vùng chứa cần được duy trì ở trạng thái sẵn sàng và có thể xử lý 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 phiên bản để phản hồi các yêu cầu đến. Hãy 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ụ hỗ trợ, 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 mức độ đồng thời trên mỗi phiên bản (mới trong thế hệ thứ 2), bạn có thể kiểm soát và điều chỉnh hành vi mở rộng quy mô cho các hàm của mình. Bản chất của ứng dụng và chức năng sẽ xác định chế độ cài đặt nào tiết kiệm chi phí nhất 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, lựa chọn CPU thấp mà không có khả năng đa luồng là lựa chọn tối ưu. Đối với những người khác mà việc khởi động nguội là một vấn đề nghiêm trọng, việc thiết lập mức độ đồng thời cao và số lượng phiên bản tối thiểu có nghĩa là một nhóm phiên bản luôn được duy trì ở trạng thái khởi động nóng để xử lý các đợt tăng đột biến lớn về lưu lượng truy cập.
Đối với các ứng dụng quy mô nhỏ nhận được rất ít lưu lượng truy cập, việc đặt số lượng phiên bản 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 tốn quá nhiều chi phí. Tuy nhiên, xin lưu ý rằng khi bạn đặt số lượng phiên bản tối đa quá thấp, các yêu cầu có thể bị loại bỏ khi đạt đến giới hạn.
Cho phép các yêu cầu đồng thời
Trong Cloud Functions for Firebase (thế hệ thứ nhất), mỗi phiên bản có thể xử lý một yêu cầu tại một thời điểm, do đó, hành vi mở rộng quy mô chỉ được thiết lập bằng các chế độ cài đặt số lượng phiên bản tối thiểu và tối đa.
Ngoài việc kiểm soát số lượng phiên bản, 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 phiên bản có thể phân phát cùng lúc bằng lựa chọn concurrency
. Giá trị mặc định cho tính đồ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 mức độ đồng thời cao hơn có thể hấp thụ các đợt tăng đột biến lưu lượng truy cập mà không cần khởi động nguội vì mỗi phiên bản có thể có một số khoảng trống. Nếu đượ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ì một phiên bản có thể xử lý thêm 25 yêu cầu mà không cần khởi động lại phiên bản mới. Ngược lại, với chế độ cài đặt đồng thời chỉ là 1, mức tăng đột biến về 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 suất tiềm năng của tính đồng thời. Trên thực tế, việc mở rộng quy mô hành vi để tối ưu hoá hiệu suất và giảm số lần khởi động nguội bằng tính đồng thời sẽ phức tạp hơn. Tính đồng thời trong Cloud Functions for Firebase thế hệ thứ 2 được hỗ trợ bởi Cloud Run và tuân theo các quy tắc của Cloud Run về tự động mở rộng quy mô phiên bản vùng chứa.
Khi thử nghiệm với chế độ cài đặt mức độ đồ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ý hình ảnh hoặc video có dung lượng lớn 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 tối đa hoá.
- Vì Cloud Functions for Firebase (thế hệ thứ 2) chạy bằng Cloud Run, nên bạn cũng có thể tham khảo hướng dẫn về Google Cloud để tối ưu hoá tính đồng thời.
- Đừng quên kiểm tra kỹ lưỡng tính năng đa tiền tệ trong môi trường thử nghiệm trước khi chuyển sang sử dụng tính năng này trong môi trường sản xuất.
Giữ ấm một số lượng tối thiểu các phiên bản
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 phiên bản để duy trì trạng thái hoạt động:
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
}
);
@https_fn.on_call(min_instances=5)
def get_autocomplete_response(event: https_fn.CallableRequest) -> https_fn.Response:
Sau đây là một số điều cần cân nhắc khi đặt giá trị số phiên bản tối thiểu:
- Nếu Cloud Functions for Firebase mở rộng quy mô ứng dụng của bạn vượt quá chế độ cài đặt, bạn sẽ gặp phải tình trạng khởi động nguội cho mỗi phiên bản vượt quá ngưỡng đó.
- Khởi động nguội có ảnh hưởng nghiêm trọng nhất đến các ứ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 một giá trị đủ cao để giảm số lần khởi động nguội khi lưu lượng truy cập tăng, thì bạn sẽ thấy độ trễ giảm đáng kể. Đối với những ứng dụng có lưu lượng truy cập ổn định, quá trình khởi động nguội có thể không ảnh hưởng nghiêm trọng đến hiệu suất.
Việc đặt số lượng phiên bản tối thiểu có thể hợp lý đối với môi trường sản xuất, nhưng thường nên tránh trong môi trường kiểm thử. Để giảm xuống 0 trong dự án kiểm thử nhưng vẫn giảm 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ị số phiên bản tối thiểu trong cấu hình có tham số:
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.`); } );
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 phiên bản tối đa cho một hàm
Bạn có thể đặt một giá trị cho số lượng phiên bản tối đa trong mã nguồn hàm. Ví dụ: hàm này đặt giới hạn là 100 phiên bản để không làm quá tải một cơ sở dữ liệu cũ giả định:
const { onMessagePublished } = require("firebase-functions/v2/pubsub");
exports.mirrorevents = onMessagePublished(
{ topic: "topic-name", maxInstances: 100 },
(event) => {
// Connect to legacy database
}
);
@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 quy mô đến giới hạn số lượng phiên bản tối đa, thì các yêu cầu mới sẽ được đưa vào hàng đợi trong 30 giây rồi bị từ chối với mã phản hồi 429 Too Many Requests
nếu không có phiên bản nào vào thời điểm đó.
Để tìm hiểu thêm về các phương pháp hay nhất khi sử dụng chế độ cài đặt số lượng phiên bản tối đa, hãy xem các phương pháp hay nhất để thiết lập số lượng phiên bản tối đa.
Đặt thời gian chờ và mức 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 về 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).
Để đặt mức phân bổ bộ nhớ và thời gian chờ trong mã nguồn hàm, hãy sử dụng các lựa chọn chung cho bộ nhớ và thời gian chờ tính bằng giây để tuỳ chỉnh máy ảo chạy các hàm của bạn. Ví dụ: hàm Cloud Storage này sử dụng 1 GiB bộ nhớ và hết thời gian chờ sau 300 giây:
exports.convertLargeFile = onObjectFinalized({
timeoutSeconds: 300,
memory: "1GiB",
}, (event) => {
// Do some complicated things that take a lot of memory and time
});
@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 thời gian chờ tính bằng giây là 540
hoặc 9 phút.
Cách đặt mức phân bổ bộ nhớ và thời gian chờ trong bảng điều khiển Google Cloud:
- 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.
- Chọn một hàm bằng cách nhấp vào tên của hàm đó trong danh sách hàm.
- Nhấp vào biểu tượng Chỉnh sửa trong trình đơn trên cùng.
- Chọn một mức phân bổ bộ nhớ trong trình đơn thả xuống có nhãn Bộ nhớ đã phân bổ.
- Nhấp vào Tuỳ chọn khác để 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 Thời gian chờ.
- Nhấp vào Lưu để cập nhật hàm.
Ghi đè giá trị mặc định của CPU
Phân bổ tối đa 2 GB bộ nhớ, mỗi hàm trong Cloud Functions for Firebase (thế hệ thứ 2) mặc định là một CPU, sau đó tăng lên 2 CPU cho 4 và 8 GB. Xin lưu ý rằng hành vi mặc định này khác biệt đáng kể so với hành vi mặc định của thế hệ thứ nhất theo những cách có thể dẫn đến chi phí cao hơn một chút cho các hàm có mức sử dụng bộ nhớ thấp như được thể hiện trong bảng sau:
RAM được phân bổ | CPU mặc định phiên bản 1 (phân số) | CPU mặc định phiên bản 2 | Mức tăng giá trên mỗi ms |
---|---|---|---|
128MB | 1/12 | 1 | 10,5 lần |
256MB | 1/6 | 1 | 5,3 lần |
512MB | 1/3 | 1 | 2,7x |
1 GB | 7/12 | 1 | 1,6 lần |
2GB | 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 các chức năng của thế hệ thứ 2 hoạt động như thế hệ thứ 1, hãy đặt chế độ mặc định của thế hệ thứ 1 làm lựa chọn chung:
// Turn off Firebase defaults
setGlobalOptions({ cpu: 'gcf_gen1' });
# Use 1st gen behavior
set_global_options(cpu="gcf_gen1")
Đối với các chức năng sử dụng nhiều CPU, thế hệ thứ 2 mang đến sự linh hoạt khi định cấu hình thêm CPU. Bạn có thể tăng tốc CPU theo từng hàm như sau:
// Boost CPU in a function:
export const analyzeImage = onObjectFinalized({ cpu: 2 }, (event) => {
// computer vision goes here
});
# Boost CPU in a function:
@storage_fn.on_object_finalized(cpu=2)
def analyze_image(event: storage_fn.CloudEvent):
# computer vision goes here