شما میتوانید توابع را با استفاده از دستورات Firebase CLI یا با تنظیم گزینههای زمان اجرا در کد منبع توابع خود، مستقر، حذف و تغییر دهید.
توابع را مستقر کنید
برای استقرار توابع، این دستور Firebase CLI را اجرا کنید:
firebase deploy --only functions
به طور پیشفرض، رابط خط فرمان فایربیس ( Firebase CLI) تمام توابع درون سورس شما را همزمان مستقر میکند. اگر پروژه شما شامل بیش از 5 تابع است، توصیه میکنیم از پرچم --only با نام توابع خاص استفاده کنید تا فقط توابعی که ویرایش کردهاید مستقر شوند. استقرار توابع خاص به این روش، فرآیند استقرار را سرعت میبخشد و به شما کمک میکند از مواجهه با سهمیههای استقرار جلوگیری کنید. به عنوان مثال:
firebase deploy --only functions:addMessage,functions:makeUppercase
هنگام استقرار تعداد زیادی از توابع، ممکن است از سهمیه استاندارد تجاوز کنید و پیامهای خطای HTTP 429 یا 500 دریافت کنید. برای حل این مشکل، توابع را در گروههای 10 تایی یا کمتر مستقر کنید.
برای لیست کامل دستورات موجود، به مرجع Firebase CLI مراجعه کنید.
به طور پیشفرض، رابط خط فرمان فایربیس ( Firebase CLI) در پوشه functions/ به دنبال کد منبع میگردد. در صورت تمایل، میتوانید توابع را در پایگاههای کد یا چندین مجموعه فایل سازماندهی کنید .
پاکسازی مصنوعات استقرار
به عنوان بخشی از استقرار توابع، تصاویر کانتینر در Artifact Registry تولید و ذخیره میشوند. این تصاویر برای اجرای توابع مستقر شده شما لازم نیستند؛ Cloud Functions یک کپی از تصویر را در استقرار اولیه دریافت و نگه میدارند، اما مصنوعات ذخیره شده برای عملکرد تابع در زمان اجرا ضروری نیستند.
اگرچه این تصاویر کانتینر اغلب کوچک هستند، اما میتوانند به مرور زمان انباشته شوند و به هزینههای ذخیرهسازی شما کمک کنند. اگر قصد دارید مصنوعات ساخته شده را بررسی کنید یا اسکنهای آسیبپذیری کانتینر را اجرا کنید، ممکن است ترجیح دهید آنها را برای مدتی نگه دارید.
برای کمک به مدیریت هزینههای ذخیرهسازی، Firebase CLI 14.0.0 و بالاتر به شما امکان میدهد یک سیاست پاکسازی Artifact Registry برای مخازنی که مصنوعات استقرار را پس از هر استقرار تابع ذخیره میکنند، پیکربندی کنید.
شما میتوانید با استفاده از دستور functions:artifacts:setpolicy به صورت دستی یک سیاست پاکسازی تنظیم یا ویرایش کنید:
firebase functions:artifacts:setpolicy
به طور پیشفرض، این دستور Artifact Registry طوری پیکربندی میکند که به طور خودکار تصاویر کانتینر قدیمیتر از ۱ روز را حذف کند. این کار تعادل معقولی بین به حداقل رساندن هزینههای ذخیرهسازی و امکان بازرسی احتمالی نسخههای اخیر ایجاد میکند.
شما میتوانید دوره نگهداری را با استفاده از گزینه --days سفارشی کنید:
firebase functions:artifacts:setpolicy --days 7 # Delete images older than 7 days
اگر توابع را در چندین منطقه مستقر میکنید، میتوانید با استفاده از گزینه --location یک سیاست پاکسازی برای یک مکان خاص تنظیم کنید:
$ firebase functions:artifacts:setpolicy --location europe-west1
از پاکسازی مصنوعات انصراف دهید
اگر ترجیح میدهید پاکسازی تصاویر را به صورت دستی مدیریت کنید، یا اگر نمیخواهید هیچ تصویری حذف شود، میتوانید بهطور کامل از سیاستهای پاکسازی انصراف دهید:
$ firebase functions:artifacts:setpolicy --none
این دستور هرگونه سیاست پاکسازی موجود که Firebase CLI تنظیم کرده است را حذف میکند و از تنظیم سیاست پاکسازی توسط Firebase پس از استقرار توابع جلوگیری میکند.
حذف توابع
شما میتوانید توابع قبلاً مستقر شده را به این روشها حذف کنید:
- به صراحت در Firebase CLI با
functions:delete - به صراحت در کنسول Google Cloud .
- به طور ضمنی با حذف تابع از منبع قبل از استقرار.
تمام عملیات حذف، قبل از حذف تابع از محیط عملیاتی، از شما میخواهند که آن را تأیید کنید.
حذف صریح تابع در Firebase CLI از آرگومانهای چندگانه و همچنین گروههای تابع پشتیبانی میکند و به شما امکان میدهد تابعی را که در یک منطقه خاص اجرا میشود، مشخص کنید. همچنین، میتوانید اعلان تأیید را نادیده بگیرید.
# 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
با حذف ضمنی تابع، firebase deploy منبع شما را تجزیه میکند و هر تابعی را که از فایل حذف شده است، از محیط عملیاتی حذف میکند.
تغییر نام، ناحیه یا تریگر یک تابع
اگر در حال تغییر نام یا تغییر ناحیهها یا تریگر توابعی هستید که ترافیک عملیاتی را مدیریت میکنند، مراحل این بخش را دنبال کنید تا از دست دادن رویدادها در حین اصلاح جلوگیری شود. قبل از دنبال کردن این مراحل، ابتدا مطمئن شوید که تابع شما idempotent است، زیرا هم نسخه جدید و هم نسخه قدیمی تابع شما در طول تغییر به طور همزمان اجرا خواهند شد.
تغییر نام یک تابع
برای تغییر نام یک تابع، یک نسخه جدید با نام جدید از تابع در کد منبع خود ایجاد کنید و سپس دو دستور استقرار جداگانه را اجرا کنید. دستور اول تابع با نام جدید را مستقر میکند و دستور دوم نسخه مستقر شده قبلی را حذف میکند. به عنوان مثال، اگر یک وبهوک فعال شده توسط HTTP دارید که میخواهید نام آن را تغییر دهید، کد را به صورت زیر اصلاح کنید:
نود جی اس
// 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!")
سپس دستورات زیر را برای استقرار تابع جدید اجرا کنید:
# Deploy new function firebase deploy --only functions:webhookNew # Wait until deployment is done; now both functions are running # Delete webhook firebase functions:delete webhook
تغییر ناحیه یا نواحی یک تابع
اگر در حال تغییر مناطق مشخص شده برای تابعی هستید که ترافیک عملیاتی را مدیریت میکند، میتوانید با انجام این مراحل به ترتیب از از دست رفتن رویداد جلوگیری کنید:
- نام تابع را تغییر دهید و ناحیه یا نواحی آن را به دلخواه تغییر دهید.
- تابع تغییر نام داده شده را مستقر کنید، که منجر به اجرای موقت کد یکسان در هر دو مجموعه از مناطق میشود.
- تابع قبلی را حذف کنید.
برای مثال، اگر یک تابع Cloud Firestore -triggered دارید که در حال حاضر در ناحیه توابع پیشفرض us-central1 قرار دارد و میخواهید آن را به asia-northeast1 منتقل کنید، ابتدا باید کد منبع خود را تغییر دهید تا نام تابع را تغییر دهید و ناحیه را اصلاح کنید.
نود جی اس
// before
exports.firestoreTrigger = onDocumentCreated(
"my-collection/{docId}",
(event) => {},
);
// after
exports.firestoreTriggerAsia = onDocumentCreated(
{
document: "my-collection/{docId}",
region: "asia-northeast1",
},
(event) => {},
);
کد بهروزرسانیشده باید فیلتر رویداد صحیح (در این مورد document ) را به همراه منطقه مشخص کند. برای اطلاعات بیشتر به Cloud Functions locations مراجعه کنید.
پایتون
# 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
سپس با اجرای دستور زیر، عملیات استقرار را انجام دهید:
firebase deploy --only functions:firestoreTriggerAsia
اکنون دو تابع یکسان در حال اجرا هستند: firestoreTrigger در us-central1 و firestoreTriggerAsia در asia-northeast1 در حال اجرا هستند.
سپس، firestoreTrigger را حذف کنید:
firebase functions:delete firestoreTrigger
اکنون فقط یک تابع وجود دارد - firestoreTriggerAsia که در asia-northeast1 اجرا میشود.
نوع ماشه یک تابع را تغییر دهید
همانطور که در طول زمان، Cloud Functions for Firebase توسعه میدهید، ممکن است به دلایل مختلف نیاز به تغییر نوع تریگر یک تابع داشته باشید. به عنوان مثال، ممکن است بخواهید از یک نوع Firebase Realtime Database یا رویداد Cloud Firestore به نوع دیگری تغییر دهید.
تغییر نوع رویداد یک تابع تنها با تغییر کد منبع و اجرای firebase deploy امکانپذیر نیست. برای جلوگیری از خطا، نوع تریگر یک تابع را با این روش تغییر دهید:
- کد منبع را اصلاح کنید تا یک تابع جدید با نوع تریگر مورد نظر را شامل شود.
- تابع را مستقر کنید، که منجر به اجرای موقت هر دو تابع قدیمی و جدید میشود.
- با استفاده از رابط خط فرمان Firebase CLI)، تابع قدیمی را به طور صریح از محیط عملیاتی حذف کنید.
برای مثال، اگر تابعی داشتید که هنگام حذف یک شیء فعال میشد، اما سپس نسخهبندی شیء را فعال کردید و میخواهید به جای آن در رویداد بایگانی مشترک شوید، ابتدا نام تابع را تغییر دهید و آن را ویرایش کنید تا نوع محرک جدید را داشته باشد.
نود جی اس
// 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):
# ...
سپس دستورات زیر را اجرا کنید تا ابتدا تابع جدید ایجاد شود، قبل از اینکه تابع قدیمی را حذف کنید:
# 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
تنظیم گزینههای زمان اجرا
Cloud Functions for Firebase به شما امکان میدهد گزینههای زمان اجرا مانند نسخه زمان اجرای Node.js و زمان انقضای هر تابع، تخصیص حافظه و حداقل/حداکثر نمونههای تابع را انتخاب کنید.
به عنوان یک روش بهینه، این گزینهها (به جز نسخه Node.js) باید روی یک شیء پیکربندی درون کد تابع تنظیم شوند. این شیء RuntimeOptions منبع اعتبار برای گزینههای زمان اجرای تابع شماست و گزینههای تنظیم شده از طریق هر روش دیگری (مانند کنسول Google Cloud یا gcloud CLI) را لغو میکند.
اگر گردش کار توسعه شما شامل تنظیم دستی گزینههای زمان اجرا از طریق کنسول Google Cloud یا gcloud CLI است و نمیخواهید این مقادیر در هر استقرار لغو شوند، گزینه preserveExternalChanges را روی true تنظیم کنید. با تنظیم این گزینه روی true ، Firebase گزینههای زمان اجرا تنظیم شده در کد شما را با تنظیمات نسخه مستقر شده فعلی تابع شما با اولویت زیر ادغام میکند:
- گزینه در کد توابع تنظیم شده است: تغییرات خارجی را نادیده بگیرید.
- گزینه در کد توابع روی
RESET_VALUEتنظیم شده است: تغییرات خارجی را با مقدار پیشفرض نادیده بگیرید. - این گزینه در کد توابع تنظیم نشده است، اما در تابع مستقر فعلی تنظیم شده است: از گزینه مشخص شده در تابع مستقر استفاده کنید.
استفاده از گزینه preserveExternalChanges: true برای اکثر سناریوها توصیه نمیشود ، زیرا کد شما دیگر منبع کامل حقیقت برای گزینههای زمان اجرا برای توابع شما نخواهد بود. اگر از آن استفاده میکنید، کنسول Google Cloud را بررسی کنید یا از gcloud CLI برای مشاهده پیکربندی کامل یک تابع استفاده کنید.
تنظیم نسخه Node.js
کیت توسعه نرمافزار Firebase برای Cloud Functions ، امکان انتخاب از محیطهای اجرایی Node.js را فراهم میکند. میتوانید انتخاب کنید که تمام توابع یک پروژه منحصراً در محیط اجرایی مربوط به یکی از این نسخههای پشتیبانیشده Node.js اجرا شوند:
- نود جی اس ۲۲
- نود جی اس ۲۰
- Node.js 18 (منسوخ شده)
نسخههای ۱۴ و ۱۶ نود.جیاس در اوایل سال ۲۰۲۵ از رده خارج شدند. استقرار با این نسخهها غیرفعال است. برای اطلاعات مهم در مورد پشتیبانی مداوم از این نسخههای نود.جیاس، به برنامه پشتیبانی مراجعه کنید.
برای تنظیم نسخه Node.js:
میتوانید نسخه را در فیلد engines در فایل package.json که در دایرکتوری functions/ شما در هنگام مقداردهی اولیه ایجاد شده است، تنظیم کنید. برای مثال، برای استفاده فقط از نسخه 20، این خط را در package.json ویرایش کنید:
"engines": {"node": "20"}
اگر از مدیر بسته Yarn استفاده میکنید یا الزامات خاص دیگری برای فیلد engines دارید، میتوانید زمان اجرای Firebase SDK for Cloud Functions را در firebase.json تنظیم کنید:
{
"functions": {
"runtime": "nodejs20" // or nodejs22
}
}
رابط خط فرمان (CLI) از مقداری که در firebase.json تنظیم شده است، به جای هر مقدار یا محدودهای که به طور جداگانه در package.json تنظیم میکنید، استفاده میکند.
زمان اجرای Node.js خود را ارتقا دهید
برای ارتقاء زمان اجرای Node.js خود:
- مطمئن شوید که پروژه شما در طرح قیمتگذاری Blaze قرار دارد.
- مطمئن شوید که از Firebase CLI نسخه ۱۱.۱۸.۰ یا بالاتر استفاده میکنید.
- مقدار
enginesرا در فایلpackage.jsonکه در دایرکتوریfunctions/در طول مقداردهی اولیه ایجاد شده است، تغییر دهید. برای مثال، اگر از نسخه ۱۸ به نسخه ۲۰ ارتقا میدهید، ورودی باید به این شکل باشد:"engines": {"node": "20"} - در صورت تمایل، میتوانید تغییرات خود را با استفاده از Firebase Local Emulator Suite آزمایش کنید.
- تمام توابع را مجدداً مستقر کنید.
یک سیستم ماژول Node.js انتخاب کنید
سیستم ماژول پیشفرض در Node.js، CommonJS (CJS) است، اما نسخههای فعلی Node.js از ماژولهای ECMAScript (ESM) نیز پشتیبانی میکنند. Cloud Functions از هر دو پشتیبانی میکند.
به طور پیشفرض، توابع شما از CommonJS استفاده میکنند. این یعنی importها و exportها به این شکل هستند:
const {onRequest} = require("firebase-functions/https");
exports.helloWorld = onRequest(async (req, res) => res.send("Hello from Firebase!"));
برای استفاده از ESM، فیلد "type": "module" در فایل package.json خود تنظیم کنید:
{
...
"type": "module",
...
}
پس از تنظیم این مورد، از سینتکس import و export ESM استفاده کنید:
import {onRequest} from "firebase-functions/https";
export const helloWorld = onRequest(async (req, res) => res.send("Hello from Firebase!"));
هر دو سیستم ماژول به طور کامل پشتیبانی میشوند. شما میتوانید هر کدام را که برای پروژه شما مناسبتر است انتخاب کنید. برای اطلاعات بیشتر به مستندات Node.js در مورد ماژولها مراجعه کنید.
تنظیم نسخه پایتون
نسخههای ۱۲.۰.۰ و بالاتر کیت توسعه نرمافزار Firebase برای Cloud Functions امکان انتخاب زمان اجرای پایتون را فراهم میکنند. نسخه زمان اجرا را در firebase.json مطابق شکل تنظیم کنید:
{
"functions": {
"runtime": "python310" // or python311
}
}
کنترل رفتار مقیاسبندی
به طور پیشفرض، Cloud Functions for Firebase تعداد نمونههای در حال اجرا را بر اساس تعداد درخواستهای ورودی مقیاسبندی میکند، و به طور بالقوه در زمان کاهش ترافیک، مقیاسبندی را به صفر میرساند. با این حال، اگر برنامه شما به تأخیر کمتری نیاز دارد و میخواهید تعداد شروعهای سرد را محدود کنید، میتوانید این رفتار پیشفرض را با مشخص کردن حداقل تعداد نمونههای کانتینر که باید گرم و آماده برای ارائه درخواستها نگه داشته شوند، تغییر دهید.
به طور مشابه، میتوانید حداکثر تعداد را برای محدود کردن مقیاسبندی نمونهها در پاسخ به درخواستهای ورودی تعیین کنید. از این تنظیم به عنوان راهی برای کنترل هزینههای خود یا محدود کردن تعداد اتصالات به یک سرویس پشتیبان مانند یک پایگاه داده استفاده کنید.
با استفاده از این تنظیمات به همراه تنظیمات همزمانی به ازای هر نمونه (که در نسل دوم جدید است)، میتوانید رفتار مقیاسبندی را برای توابع خود کنترل و تنظیم کنید. ماهیت برنامه و تابع شما تعیین میکند که کدام تنظیمات مقرون به صرفهتر هستند و منجر به بهترین عملکرد میشوند.
برای برخی از برنامههای کاربردی با ترافیک کم، گزینه CPU پایینتر بدون چندهمزمانی بهینه است. برای برخی دیگر که شروع سرد یک مسئله حیاتی است، تنظیم همزمانی بالا و حداقل نمونهها به این معنی است که مجموعهای از نمونهها همیشه گرم نگه داشته میشوند تا بتوانند افزایش شدید ترافیک را مدیریت کنند.
برای برنامههای کوچکتر که ترافیک بسیار کمی دریافت میکنند، تنظیم حداکثر تعداد نمونهها در پایینترین سطح با همزمانی بالا به این معنی است که برنامه میتواند بدون متحمل شدن هزینههای اضافی، حجم زیادی از ترافیک را مدیریت کند. با این حال، به خاطر داشته باشید که وقتی حداکثر تعداد نمونهها خیلی پایین تنظیم شود، ممکن است درخواستها پس از رسیدن به سقف، لغو شوند.
اجازه درخواستهای همزمان
در Cloud Functions for Firebase (نسل اول)، هر نمونه میتوانست در هر زمان یک درخواست را مدیریت کند، بنابراین رفتار مقیاسبندی فقط با تنظیمات حداقل و حداکثر نمونهها تنظیم میشد. علاوه بر کنترل تعداد نمونهها، در Cloud Functions for Firebase (نسل دوم) میتوانید تعداد درخواستهایی را که هر نمونه میتواند همزمان ارائه دهد با گزینه concurrency کنترل کنید. مقدار پیشفرض برای همزمانی ۸۰ است، اما میتوانید آن را روی هر عدد صحیحی بین ۱ تا ۱۰۰۰ تنظیم کنید.
توابعی با تنظیمات همزمانی بالاتر میتوانند افزایش ناگهانی ترافیک را بدون شروع سرد جذب کنند، زیرا هر نمونه احتمالاً مقداری فضای خالی دارد. اگر یک نمونه برای مدیریت حداکثر ۵۰ درخواست همزمان پیکربندی شده باشد، اما در حال حاضر فقط ۲۵ درخواست را مدیریت میکند، میتواند بدون نیاز به شروع سرد یک نمونه جدید، افزایش ناگهانی ۲۵ درخواست اضافی را مدیریت کند. در مقابل، با تنظیم همزمانی فقط ۱، این افزایش ناگهانی در درخواستها میتواند منجر به ۲۵ شروع سرد شود.
این سناریوی سادهشده، پتانسیل افزایش بهرهوری همزمانی را نشان میدهد. در واقعیت، مقیاسبندی رفتار برای بهینهسازی بهرهوری و کاهش شروعهای سرد با همزمانی پیچیدهتر است. همزمانی در Cloud Functions for Firebase 2nd gen توسط Cloud Run پشتیبانی میشود و از قوانین مقیاسبندی خودکار نمونه کانتینر Cloud Run پیروی میکند.
هنگام آزمایش با تنظیمات همزمانی بالاتر در Cloud Functions for Firebase (نسل دوم)، موارد زیر را در نظر داشته باشید:
- تنظیمات همزمانی بالاتر ممکن است برای عملکرد بهینه به CPU و RAM بالاتری نیاز داشته باشند تا زمانی که به یک حد عملی برسند. به عنوان مثال، تابعی که پردازش تصویر یا ویدئوی سنگین انجام میدهد، ممکن است منابع لازم برای رسیدگی به ۱۰۰۰ درخواست همزمان را نداشته باشد، حتی زمانی که تنظیمات CPU و RAM آن در حداکثر مقدار خود باشد.
- از آنجایی که Cloud Functions for Firebase (نسل دوم) توسط Cloud Run پشتیبانی میشوند، میتوانید برای بهینهسازی همزمانی به راهنماییهای Google Cloud نیز مراجعه کنید.
- قبل از تغییر به چندهمزمانی در محیط عملیاتی، حتماً چندهمزمانی را در یک محیط آزمایشی به طور کامل آزمایش کنید.
حداقل تعداد دفعات را گرم نگه دارید
شما میتوانید حداقل تعداد نمونهها را برای یک تابع در کد منبع تنظیم کنید. برای مثال، این تابع حداقل ۵ نمونه را برای گرم نگه داشتن تنظیم میکند:
نود جی اس
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:
هنگام تعیین حداقل مقدار نمونه، نکاتی وجود دارد که باید در نظر بگیرید:
- اگر Cloud Functions for Firebase برنامه شما را بالاتر از تنظیمات شما مقیاسبندی کند، برای هر نمونه بالاتر از آن آستانه، شروع سرد را تجربه خواهید کرد.
- شروع سرد (Cold Starts) شدیدترین تأثیر را روی برنامههایی با ترافیک متغیر دارد. اگر برنامه شما ترافیک متغیری دارد و مقداری را به اندازه کافی بالا تنظیم کنید که شروع سرد با هر افزایش ترافیک کاهش یابد، شاهد کاهش قابل توجه تأخیر خواهید بود. برای برنامههایی با ترافیک ثابت، شروع سرد احتمالاً تأثیر شدیدی بر عملکرد نخواهد داشت.
تنظیم حداقل نمونهها میتواند برای محیطهای عملیاتی منطقی باشد، اما معمولاً باید در محیطهای آزمایشی از آن اجتناب شود. برای اینکه در پروژه آزمایشی خود به صفر برسید اما همچنان شروعهای سرد را در پروژه عملیاتی خود کاهش دهید، میتوانید مقدار حداقل نمونهها را در پیکربندی پارامتری خود تنظیم کنید:
نود جی اس
const { onRequest } = require('firebase-functions/https'); 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 = onRequest( { minInstances: minInstancesConfig }, (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.")
محدود کردن حداکثر تعداد نمونهها برای یک تابع
شما میتوانید در کد منبع تابع، مقداری برای حداکثر تعداد نمونهها تعیین کنید. برای مثال، این تابع محدودیت ۱۰۰ نمونه را تعیین میکند تا یک پایگاه داده فرضی قدیمی را تحت الشعاع قرار ندهد:
نود جی اس
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
اگر یک تابع HTTP تا حداکثر تعداد نمونهها افزایش مقیاس داده شود، درخواستهای جدید به مدت 30 ثانیه در صف انتظار قرار میگیرند و سپس اگر تا آن زمان هیچ نمونهای در دسترس نباشد، با کد پاسخ 429 Too Many Requests رد میشوند.
برای کسب اطلاعات بیشتر در مورد بهترین شیوهها برای استفاده از تنظیمات حداکثر نمونهها، این بهترین شیوهها برای تنظیم حداکثر نمونهها را بررسی کنید.
تنظیم حساب کاربری سرویس
حسابهای کاربری پیشفرض سرویس برای توابع، مجموعهای گسترده از مجوزها را دارند که به شما امکان میدهد با سایر سرویسهای Firebase و Google Cloud تعامل داشته باشید:
- توابع نسل دوم: PROJECT_NUMBER -compute@developer.gserviceaccount.com (با نام حساب سرویس پیشفرض Compute Engine )
- توابع نسل اول: PROJECT_ID @ appspot.gserviceaccount.com (با نام حساب سرویس پیشفرض App Engine )
ممکن است بخواهید حساب سرویس پیشفرض را لغو کنید و یک تابع را دقیقاً به منابع مورد نیاز محدود کنید. میتوانید این کار را با ایجاد یک حساب سرویس سفارشی و اختصاص آن به تابع مناسب با استفاده از مقدار پیکربندی serviceAccount انجام دهید:
const { onRequest } = require("firebase-functions/https");
exports.helloWorld = onRequest(
{
// This function doesn't access other Firebase project resources, so it uses a limited service account.
serviceAccount:
"my-limited-access-sa@", // or prefer the full form: "my-limited-access-sa@my-project.iam.gserviceaccount.com"
},
(request, response) => {
response.send("Hello from Firebase!");
},
);
اگر میخواهید برای همه توابع خود یک حساب سرویس یکسان تنظیم کنید، میتوانید این کار را با تابع setGlobalOptions انجام دهید.
تنظیم زمان انقضا و تخصیص حافظه
در برخی موارد، توابع شما ممکن است الزامات خاصی برای مقدار timeout طولانی یا تخصیص زیاد حافظه داشته باشند. میتوانید این مقادیر را یا در کنسول Google Cloud یا در کد منبع تابع (فقط Firebase) تنظیم کنید.
برای تنظیم تخصیص حافظه و زمان انقضا در کد منبع توابع، از گزینههای سراسری برای حافظه و ثانیههای انقضا استفاده کنید تا ماشین مجازی که توابع شما را اجرا میکند، سفارشیسازی شود. برای مثال، این تابع Cloud Storage از ۱ گیگابایت حافظه استفاده میکند و پس از ۳۰۰ ثانیه زمان انقضا دارد:
نود جی اس
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.
حداکثر مقدار برای زمان انقضا 540 ثانیه یا ۹ دقیقه است.
برای تنظیم تخصیص حافظه و زمان انقضا در کنسول Google Cloud :
- در کنسول Google Cloud ، از منوی سمت چپ، Cloud Functions for Firebase را انتخاب کنید.
- با کلیک روی نام یک تابع در لیست توابع، آن را انتخاب کنید.
- روی آیکون ویرایش در منوی بالا کلیک کنید.
- از منوی کشویی با عنوان « حافظه اختصاص داده شده» ، یک تخصیص حافظه را انتخاب کنید.
- برای نمایش گزینههای پیشرفته، روی «بیشتر» کلیک کنید و در کادر متن «زمان انتظار» تعداد ثانیهها را وارد کنید.
- برای بهروزرسانی تابع، روی ذخیره کلیک کنید.
نادیده گرفتن پیشفرضهای CPU
تا ۲ گیگابایت حافظه اختصاص داده شده، هر تابع در Cloud Functions for Firebase (نسل دوم) به طور پیشفرض روی یک پردازنده مرکزی قرار میگیرد و سپس برای ۴ و ۸ گیگابایت به ۲ پردازنده مرکزی افزایش مییابد. توجه داشته باشید که این به طور قابل توجهی با رفتار پیشفرض نسل اول متفاوت است، به طوری که میتواند منجر به هزینههای کمی بالاتر برای توابع با حافظه کم شود، همانطور که در جدول زیر بیان شده است:
| رم اختصاص داده شده | پردازنده پیشفرض نسخه ۱ (کسری) | پردازنده پیشفرض نسخه ۲ | افزایش قیمت به ازای هر میلیثانیه |
|---|---|---|---|
| ۱۲۸ مگابایت | ۱/۱۲ | ۱ | ۱۰.۵ برابر |
| ۲۵۶ مگابایت | ۱/۶ | ۱ | ۵.۳ برابر |
| ۵۱۲ مگابایت | ۱/۳ | ۱ | ۲.۷ برابر |
| ۱ گیگابایت | ۱۲/۷ | ۱ | ۱.۶ برابر |
| ۲ گیگابایت | ۱ | ۱ | ۱ عدد |
| ۴ گیگابایت | ۲ | ۲ | ۱ عدد |
| ۸ گیگابایت | ۲ | ۲ | ۱ عدد |
| ۱۶ گیگابایت | ناموجود | ۴ | ناموجود |
اگر رفتار نسل اول را برای توابع نسل دوم خود ترجیح میدهید، پیشفرضهای نسل اول را به عنوان یک گزینه سراسری تنظیم کنید:
نود جی اس
// Turn off Firebase defaults
setGlobalOptions({ cpu: 'gcf_gen1' });
پایتون
# Use 1st gen behavior
set_global_options(cpu="gcf_gen1")
برای عملکردهایی که به شدت به CPU نیاز دارند، نسل دوم انعطافپذیری لازم برای پیکربندی CPU اضافی را فراهم میکند. میتوانید CPU را بر اساس هر عملکرد، همانطور که نشان داده شده است، تقویت کنید:
نود جی اس
// 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