Funkcje możesz wdrażać, usuwać i modyfikować za pomocą Firebase poleceń interfejsu wiersza poleceń lub ustawiając opcje środowiska wykonawczego w kodzie źródłowym funkcji.
Wdrażanie funkcji
Aby wdrożyć funkcje, uruchom to polecenie interfejsu wiersza poleceń Firebase:
firebase deploy --only functions
Domyślnie interfejs Firebase wdraża wszystkie funkcje w źródle jednocześnie. Jeśli Twój projekt zawiera więcej niż 5 funkcji, zalecamy użycie flagi --only
z nazwami konkretnych funkcji, aby wdrożyć tylko te funkcje, które zostały przez Ciebie zmodyfikowane. Wdrażanie konkretnych funkcji w ten sposób przyspiesza proces wdrażania i pomaga uniknąć przekroczenia limitów wdrażania. Przykład:
firebase deploy --only functions:addMessage,functions:makeUppercase
Podczas wdrażania dużej liczby funkcji możesz przekroczyć standardowy limit i otrzymać komunikaty o błędach HTTP 429 lub 500. Aby rozwiązać ten problem, wdrażaj funkcje w grupach liczących maksymalnie 10 elementów.
Pełną listę dostępnych poleceń znajdziesz w Firebasedokumentacji interfejsu CLI.
Domyślnie interfejs Firebase CLI szuka kodu źródłowego w folderze functions/
. Jeśli wolisz, możesz organizować funkcje w bazach kodu lub w kilku zestawach plików.
Usuwanie artefaktów wdrożenia
W ramach wdrażania funkcji generowane są obrazy kontenerów, które są przechowywane w Artifact Registry. Te obrazy nie są wymagane do działania wdrożonych funkcji. Cloud Functions pobiera i przechowuje kopię obrazu podczas początkowego wdrożenia, ale przechowywane artefakty nie są potrzebne do działania funkcji w czasie wykonywania.
Obrazy kontenerów są zwykle małe, ale z czasem mogą się gromadzić i zwiększać koszty przechowywania. Możesz je zachować przez pewien czas, jeśli planujesz sprawdzić utworzone artefakty lub przeprowadzić skanowanie kontenera pod kątem luk w zabezpieczeniach.
Aby pomóc w zarządzaniu kosztami przechowywania, Firebaseinterfejs CLI w wersji 14.0.0 i nowszych umożliwia skonfigurowanie Artifact Registryzasady czyszczenia w przypadku repozytoriów, w których po każdym wdrożeniu funkcji są przechowywane artefakty wdrożenia.
Zasady czyszczenia możesz skonfigurować lub edytować ręcznie za pomocą polecenia functions:artifacts:setpolicy
:
firebase functions:artifacts:setpolicy
Domyślnie to polecenie konfiguruje Artifact Registry tak, aby automatycznie usuwać obrazy kontenerów starsze niż 1 dzień. Zapewnia to rozsądną równowagę między minimalizacją kosztów przechowywania a możliwością sprawdzenia ostatnich kompilacji.
Okres przechowywania możesz dostosować za pomocą opcji --days
:
firebase functions:artifacts:setpolicy --days 7 # Delete images older than 7 days
Jeśli wdrażasz funkcje w wielu regionach, możesz skonfigurować zasady czyszczenia dla konkretnej lokalizacji za pomocą opcji --location
:
$ firebase functions:artifacts:setpolicy --location europe-west1
Rezygnacja z czyszczenia artefaktów
Jeśli wolisz ręcznie zarządzać czyszczeniem obrazów lub nie chcesz usuwać żadnych obrazów, możesz całkowicie zrezygnować z zasad czyszczenia:
$ firebase functions:artifacts:setpolicy --none
To polecenie usuwa wszystkie istniejące zasady czyszczenia, które zostały skonfigurowane przez interfejs Firebase, i uniemożliwia Firebase skonfigurowanie zasad czyszczenia po wdrożeniu funkcji.
Usuwanie funkcji
Wcześniej wdrożone funkcje możesz usunąć w ten sposób:
- wyraźnie w interfejsie wiersza poleceń Firebase za pomocą polecenia
functions:delete
. - wyraźnie w Google Cloudkonsoli.
- niejawnie, usuwając funkcję ze źródła przed wdrożeniem.
Wszystkie operacje usuwania wymagają potwierdzenia przed usunięciem funkcji z wersji produkcyjnej.
Jawne usuwanie funkcji w Firebase CLI obsługuje wiele argumentów, a także grupy funkcji i umożliwia określenie funkcji działającej w danym regionie. Możesz też pominąć prośbę o potwierdzenie.
# 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
W przypadku niejawnego usuwania funkcji firebase deploy
analizuje źródło i usuwa z wersji produkcyjnej wszystkie funkcje, które zostały usunięte z pliku.
Modyfikowanie nazwy, regionu lub aktywatora funkcji
Jeśli zmieniasz nazwę lub region albo aktywator funkcji, które obsługują ruch produkcyjny, wykonaj czynności opisane w tej sekcji, aby uniknąć utraty zdarzeń podczas modyfikacji. Zanim wykonasz te czynności, upewnij się, że funkcja jest idempotentna, ponieważ podczas zmiany będą działać jednocześnie nowa i stara wersja funkcji.
Zmienianie nazwy funkcji
Aby zmienić nazwę funkcji, utwórz nową wersję funkcji ze zmienioną nazwą w źródle, a potem uruchom 2 osobne polecenia wdrażania. Pierwsze polecenie wdraża nowo nazwaną funkcję, a drugie usuwa wcześniej wdrożoną wersję. Jeśli na przykład chcesz zmienić nazwę wywoływanego przez HTTP webhooka, zmień kod w ten sposób:
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!")
Następnie uruchom te polecenia, aby wdrożyć nową funkcję:
# Deploy new function firebase deploy --only functions:webhookNew # Wait until deployment is done; now both functions are running # Delete webhook firebase functions:delete webhook
Zmienianie regionu lub regionów funkcji
Jeśli zmieniasz określone regiony w przypadku funkcji obsługującej ruch produkcyjny, możesz zapobiec utracie zdarzeń, wykonując te czynności w podanej kolejności:
- Zmień nazwę funkcji i w razie potrzeby zmień region lub regiony.
- Wdróż funkcję o nowej nazwie, co spowoduje tymczasowe uruchomienie tego samego kodu w obu zestawach regionów.
- Usuń poprzednią funkcję.
Jeśli na przykład masz funkcję wywoływaną przez Cloud Firestore, która obecnie znajduje się w domyślnym regionie funkcji us-central1
, i chcesz ją przenieść do regionu asia-northeast1
, musisz najpierw zmodyfikować kod źródłowy, aby zmienić nazwę funkcji i region.
Node.js
// before
exports.firestoreTrigger = onDocumentCreated(
"my-collection/{docId}",
(event) => {},
);
// after
exports.firestoreTriggerAsia = onDocumentCreated(
{
document: "my-collection/{docId}",
region: "asia-northeast1",
},
(event) => {},
);
Zaktualizowany kod powinien zawierać prawidłowy filtr zdarzeń (w tym przypadku document
) oraz region. Więcej informacji znajdziesz w sekcji Cloud Functionslokalizacje.
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
Następnie wdróż aplikację, uruchamiając to polecenie:
firebase deploy --only functions:firestoreTriggerAsia
Teraz działają 2 identyczne funkcje: firestoreTrigger
w us-central1
i firestoreTriggerAsia
w asia-northeast1
.
Następnie usuń firestoreTrigger
:
firebase functions:delete firestoreTrigger
Teraz jest tylko jedna funkcja – firestoreTriggerAsia
, która działa w asia-northeast1
.
Zmienianie typu wywołania funkcji
W miarę rozwoju wdrożenia Cloud Functions for Firebase możesz z różnych powodów potrzebować zmiany typu wyzwalacza funkcji. Możesz na przykład zmienić typ zdarzenia Firebase Realtime Database lub Cloud Firestore na inny.
Nie można zmienić typu zdarzenia funkcji, zmieniając tylko kod źródłowy i uruchamiając polecenie firebase deploy
. Aby uniknąć błędów, zmień typ reguły funkcji, wykonując te czynności:
- Zmodyfikuj kod źródłowy, aby uwzględnić nową funkcję z odpowiednim typem wyzwalacza.
- Wdróż funkcję, co spowoduje tymczasowe uruchomienie zarówno starej, jak i nowej funkcji.
- Usuń starą funkcję z wersji produkcyjnej za pomocą interfejsu wiersza poleceń Firebase.
Jeśli na przykład masz funkcję, która była wywoływana po usunięciu obiektu, ale następnie włączysz wersjonowanie obiektów i chcesz zamiast tego subskrybować zdarzenie archiwizacji, najpierw zmień nazwę funkcji i zmodyfikuj ją, aby miała nowy typ aktywatora.
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):
# ...
Następnie uruchom te polecenia, aby najpierw utworzyć nową funkcję, a potem usunąć starą:
# 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
Ustawianie opcji środowiska wykonawczego
Cloud Functions for Firebase umożliwia wybieranie opcji środowiska wykonawczego, takich jak wersja środowiska wykonawczego Node.js, limit czasu poszczególnych funkcji, przydział pamięci oraz minimalna i maksymalna liczba instancji funkcji.
Zgodnie ze sprawdzoną metodą te opcje (z wyjątkiem wersji Node.js) należy ustawić w obiekcie konfiguracji w kodzie funkcji. Ten obiekt RuntimeOptions
jest źródłem informacji o opcjach środowiska wykonawczego funkcji i zastępuje opcje ustawione w inny sposób (np. w konsoli Google Cloud lub w interfejsie gcloud CLI).
Jeśli Twój proces programowania obejmuje ręczne ustawianie opcji środowiska wykonawczego za pomocą konsoli Google Cloud lub interfejsu gcloud CLI i nie chcesz, aby te wartości były zastępowane przy każdym wdrożeniu, ustaw opcję preserveExternalChanges
na true
.
Jeśli ta opcja jest ustawiona na true
, Firebase łączy opcje środowiska wykonawczego ustawione w kodzie z ustawieniami aktualnie wdrożonej wersji funkcji w tej kolejności:
- Opcja jest ustawiona w kodzie funkcji: zastępuje zmiany zewnętrzne.
- Opcja jest ustawiona na
RESET_VALUE
w kodzie funkcji: zastąp zmiany zewnętrzne wartością domyślną. - Opcja nie jest ustawiona w kodzie funkcji, ale jest ustawiona w obecnie wdrożonej funkcji: użyj opcji określonej we wdrożonej funkcji.
Używanie opcji preserveExternalChanges: true
jest niezalecane w większości przypadków, ponieważ kod nie będzie już pełnym źródłem informacji o opcjach środowiska wykonawczego funkcji. Jeśli go używasz, sprawdź konsolę Google Cloud lub użyj interfejsu wiersza poleceń gcloud, aby wyświetlić pełną konfigurację funkcji.
Ustawianie wersji Node.js
Pakiet SDK Firebase dla Cloud Functions umożliwia wybór środowiska wykonawczego Node.js. Możesz uruchamiać wszystkie funkcje w projekcie wyłącznie w środowisku wykonawczym odpowiadającym jednej z tych obsługiwanych wersji Node.js:
- Node.js 22
- Node.js 20
- Node.js 18 (wycofana)
Wersje Node.js 14 i 16 zostały wycofane na początku 2025 r. Wdrażanie w tych wersjach jest wyłączone. Ważne informacje o bieżącym wsparciu dla tych wersji Node.js znajdziesz w harmonogramie pomocy.
Aby ustawić wersję Node.js:
Wersję możesz ustawić w polu engines
w pliku package.json
, który został utworzony w katalogu functions/
podczas inicjowania.
Jeśli na przykład chcesz używać tylko wersji 20, zmień ten wiersz w pliku package.json
:
"engines": {"node": "20"}
Jeśli używasz menedżera pakietów Yarn lub masz inne wymagania dotyczące pola engines
, możesz ustawić środowisko wykonawcze pakietu SDK Firebase dla Cloud Functions w firebase.json
:
{
"functions": {
"runtime": "nodejs20" // or nodejs22
}
}
Interfejs CLI używa wartości ustawionej w firebase.json
zamiast dowolnej wartości lub zakresu ustawionego osobno w package.json
.
Uaktualnianie środowiska wykonawczego Node.js
Aby uaktualnić środowisko wykonawcze Node.js:
- Sprawdź, czy Twój projekt jest objęty abonamentem Blaze.
- Upewnij się, że używasz Firebase CLI w wersji 11.18.0 lub nowszej.
- Zmień wartość
engines
w plikupackage.json
, który został utworzony w katalogufunctions/
podczas inicjalizacji. Jeśli na przykład uaktualniasz wersję 18 do wersji 20, wpis powinien wyglądać tak:"engines": {"node": "20"}
- Opcjonalnie możesz przetestować zmiany za pomocą Firebase Local Emulator Suite.
- Ponownie wdrożyć wszystkie funkcje.
Ustawianie wersji Pythona
Firebase Pakiet SDK w wersji Cloud Functions 12.0.0 i nowszych umożliwia wybór środowiska wykonawczego Python. Ustaw wersję środowiska wykonawczego w firebase.json
w ten sposób:
{
"functions": {
"runtime": "python310" // or python311
}
}
Kontrolowanie zachowania przy skalowaniu
Domyślnie Cloud Functions for Firebase skaluje liczbę uruchomionych instancji na podstawie liczby żądań przychodzących, co w okresach mniejszego ruchu może oznaczać zmniejszenie liczby instancji do zera. Jeśli jednak Twoja aplikacja wymaga krótszego czasu oczekiwania i chcesz ograniczyć liczbę uruchomień „na zimno”, możesz zmienić to domyślne działanie, określając minimalną liczbę instancji kontenera, które mają być utrzymywane w gotowości do obsługi żądań.
Podobnie możesz ustawić maksymalną liczbę, aby ograniczyć skalowanie instancji w odpowiedzi na przychodzące żądania. Użyj tego ustawienia, aby kontrolować koszty lub ograniczyć liczbę połączeń z usługą wspierającą, np. z bazą danych.
Używając tych ustawień w połączeniu z ustawieniem współbieżności dla poszczególnych instancji (nowość w przypadku funkcji 2 generacji), możesz kontrolować i dostosowywać sposób skalowania funkcji. Rodzaj aplikacji i jej funkcja określą, które ustawienia są najbardziej opłacalne i przynoszą najlepsze wyniki.
W przypadku niektórych aplikacji o niskim natężeniu ruchu optymalna jest opcja z mniejszą liczbą procesorów bez wielowątkowości. W przypadku innych funkcji, w których uruchamianie „na zimno” jest krytycznym problemem, ustawienie wysokiej współbieżności i minimalnej liczby instancji oznacza, że zestaw instancji jest zawsze utrzymywany w gotowości do obsługi dużych skoków natężenia ruchu.
W przypadku mniejszych aplikacji, które generują bardzo mały ruch, ustawienie niskiej maksymalnej liczby instancji przy dużej liczbie jednoczesnych żądań oznacza, że aplikacja może obsługiwać nagłe wzrosty ruchu bez ponoszenia nadmiernych kosztów. Pamiętaj jednak, że jeśli wartość parametru maximum instances jest zbyt niska, po osiągnięciu limitu żądania mogą zostać odrzucone.
Zezwalaj na równoczesne żądania
W Cloud Functions for Firebase (1 generacji) każda instancja mogła obsługiwać tylko 1 żądanie naraz, więc skalowanie było konfigurowane tylko za pomocą ustawień minimalnej i maksymalnej liczby instancji.
Oprócz kontrolowania liczby instancji w Cloud Functions for Firebase (2 generacji) możesz kontrolować liczbę żądań, które każda instancja może obsługiwać jednocześnie, za pomocą opcji concurrency
. Domyślna wartość równoczesności to 80, ale możesz ją ustawić na dowolną liczbę całkowitą z zakresu od 1 do 1000.
Funkcje z wyższymi ustawieniami współbieżności mogą absorbować skoki ruchu bez zimnego startu, ponieważ każda instancja ma prawdopodobnie pewien zapas mocy obliczeniowej. Jeśli instancja jest skonfigurowana do obsługi maksymalnie 50 jednoczesnych żądań, ale obecnie obsługuje tylko 25 żądania, może obsłużyć nagły wzrost o 25 dodatkowych żądań bez konieczności uruchamiania nowej instancji. Z kolei przy ustawieniu współbieżności na poziomie 1 ten nagły wzrost liczby żądań może spowodować 25 uruchomień „na zimno”.
Ten uproszczony scenariusz pokazuje potencjalne korzyści w zakresie wydajności, jakie można uzyskać dzięki współbieżności. W rzeczywistości skalowanie zachowań w celu optymalizacji wydajności i ograniczenia zimnych startów przy użyciu współbieżności jest bardziej złożone. Równoczesność w Cloud Functions for Firebase 2 generacji jest oparta na Cloud Run i podlega regułom Cloud Run dotyczącym autoskalowania instancji kontenera.
Podczas eksperymentowania z wyższymi ustawieniami współbieżności w Cloud Functions for Firebase(2 generacji) pamiętaj o tych kwestiach:
- Wyższe ustawienia współbieżności mogą wymagać większej mocy obliczeniowej procesora i większej ilości pamięci RAM, aby osiągnąć optymalną wydajność, aż do osiągnięcia praktycznego limitu. Funkcja, która wykonuje intensywne przetwarzanie obrazów lub filmów, może na przykład nie mieć wystarczających zasobów do obsługi 1000 równoczesnych żądań, nawet jeśli ustawienia procesora i pamięci RAM są zmaksymalizowane.
- Cloud Functions for Firebase (2 generacji) korzysta z Cloud Run, więc możesz też zapoznać się z Google Cloud, aby dowiedzieć się więcej o optymalizacji współbieżności.
- Przed przejściem na obsługę wielu walut w środowisku produkcyjnym dokładnie przetestuj ją w środowisku testowym.
Utrzymywanie w gotowości minimalnej liczby instancji
Minimalną liczbę instancji funkcji możesz ustawić w kodzie źródłowym. Na przykład ta funkcja ustawia minimalną liczbę 5 instancji, które mają być utrzymywane w gotowości:
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:
Podczas ustawiania minimalnej liczby instancji warto pamiętać o tych kwestiach:
- Jeśli Cloud Functions for Firebase skaluje aplikację powyżej ustawionego limitu, każde wystąpienie powyżej tego progu będzie uruchamiane „na zimno”.
- Uruchamianie „na zimno” ma największy wpływ na aplikacje z nieregularnym ruchem. Jeśli Twoja aplikacja ma skokowe natężenie ruchu, a ustawisz wartość na tyle wysoką, że zimne starty będą rzadsze przy każdym wzroście natężenia ruchu, zauważysz znaczne zmniejszenie opóźnienia. W przypadku aplikacji o stałym natężeniu ruchu uruchomienia „na zimno” nie powinny mieć dużego wpływu na wydajność.
Ustawienie minimalnej liczby instancji może być przydatne w środowiskach produkcyjnych, ale zwykle należy go unikać w środowiskach testowych. Aby w projekcie testowym skalować do zera, ale nadal ograniczać uruchomienia „na zimno” w projekcie produkcyjnym, możesz ustawić minimalną liczbę instancji w konfiguracji sparametryzowanej:
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.")
Ograniczanie maksymalnej liczby instancji funkcji
W kodzie źródłowym funkcji możesz ustawić wartość maksymalnej liczby instancji. Ta funkcja ustawia na przykład limit 100 instancji, aby nie przeciążać hipotetycznej starszej bazy danych:
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
Jeśli funkcja HTTP zostanie przeskalowana do maksymalnej liczby instancji, nowe żądania będą przez 30 sekund umieszczane w kolejce, a potem odrzucane z kodem odpowiedzi 429 Too Many Requests
, jeśli do tego czasu nie będzie dostępna żadna instancja.
Więcej informacji o sprawdzonych metodach korzystania z ustawień maksymalnej liczby instancji znajdziesz w tych sprawdzonych metodach ustawiania maksymalnej liczby instancji.
Ustawianie czasu oczekiwania i przydziału pamięci
W niektórych przypadkach funkcje mogą mieć specjalne wymagania dotyczące długiego czasu oczekiwania lub dużej ilości pamięci. Wartości te możesz ustawić w Google Cloudkonsoli lub w kodzie źródłowym funkcji (tylko w Firebase).
Aby ustawić alokację pamięci i limit czasu w kodzie źródłowym funkcji, użyj opcji globalnych dotyczących pamięci i limitu czasu w sekundach, aby dostosować maszynę wirtualną, na której działają Twoje funkcje. Na przykład ta funkcja Cloud Storage używa 1 GiB pamięci i przekracza limit czasu po 300 sekundach:
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.
Maksymalna wartość limitu czasu w sekundach to 540
, czyli 9 minut.
Aby ustawić alokację pamięci i limit czasu w konsoli Google Cloud:
- W konsoli Google Cloud wybierz Cloud Functions for Firebase z menu po lewej stronie.
- Wybierz funkcję, klikając jej nazwę na liście funkcji.
- W menu u góry kliknij ikonę Edytuj.
- Wybierz przydział pamięci z menu Przydzielona pamięć.
- Kliknij Więcej, aby wyświetlić opcje zaawansowane, i wpisz liczbę sekund w polu tekstowym Limit czasu.
- Aby zaktualizować funkcję, kliknij Zapisz.
Zastąp domyślne ustawienia procesora
Maksymalnie 2 GB pamięci, każda funkcja w Cloud Functions for Firebase (2 generacji) domyślnie korzysta z 1 procesora, a następnie zwiększa się do 2 procesorów w przypadku 4 GB i 8 GB. Pamiętaj, że znacznie różni się to od domyślnego działania funkcji 1 generacji, co może prowadzić do nieco wyższych kosztów w przypadku funkcji o niskim poziomie pamięci, jak pokazano w tej tabeli:
Przydzielona pamięć RAM | Domyślny procesor w wersji 1 (ułamkowy) | Domyślny procesor w wersji 2 | Wzrost ceny za milisekundę |
---|---|---|---|
128 MB | 1/12 | 1 | 10,5x |
256 MB | 1/6 | 1 | 5,3x |
512 MB | 1/3 | 1 | 2,7x |
1 GB | 7/12 | 1 | 1,6x |
2 GB | 1 | 1 | 1x |
4 GB | 2 | 2 | 1x |
8 GB | 2 | 2 | 1x |
16 GB | Nie dotyczy | 4 | Nie dotyczy |
Jeśli wolisz, aby funkcje 2 generacji działały jak funkcje 1 generacji, ustaw domyślne wartości 1 generacji jako opcję globalną:
Node.js
// Turn off Firebase defaults
setGlobalOptions({ cpu: 'gcf_gen1' });
Python
# Use 1st gen behavior
set_global_options(cpu="gcf_gen1")
W przypadku funkcji wymagających dużej mocy obliczeniowej procesora funkcje 2 generacji umożliwiają skonfigurowanie dodatkowego procesora. Możesz zwiększyć moc obliczeniową procesora dla poszczególnych funkcji w ten sposób:
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