مدیریت کارکردها

می‌توانید توابع را بااستفاده از فرمان‌های Firebase CLI یا با تنظیم گزینه‌های زمان اجرا در کد منبع توابع، مستقر، حذف، و اصلاح کنید.

مستقر کردن توابع

برای استقرار توابع، این فرمان Firebase CLI را اجرا کنید:

firebase deploy --only functions

به‌طور پیش‌فرض، Firebase CLI همه توابع را به‌طور هم‌زمان در منبع شما مستقر می‌کند. اگر پروژه‌تان بیش‌از ۵ تابع دارد، توصیه می‌کنیم از پرچم --only با نام‌های تابع خاص استفاده کنید تا فقط تابع‌هایی را که ویرایش کرده‌اید مستقر کنید. استقرار توابع خاص به این روش فرایند استقرار را سرعت می‌بخشد و به شما کمک می‌کند تا با سهمیه‌های استقرار مواجه نشوید. برای مثال:

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

هنگام استقرار تعداد زیادی تابع، ممکن است از سهمیه استاندارد فراتر بروید و پیام‌های خطای HTTP 429 یا 500 دریافت کنید. برای حل این مشکل، توابع را در گروه‌های ۱۰ تایی یا کمتر مستقر کنید.

برای مشاهده فهرست کامل فرمان‌های دردسترس، به مرجع میانای خط فرمان Firebase مراجعه کنید.

به‌طور پیش‌فرض، 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 راه‌اندازی کرده است برمی‌دارد و از راه‌اندازی خط‌مشی پاک‌سازی توسط Firebase پس‌از استقرار تابع جلوگیری می‌کند.

حذف توابع

می‌توانید توابع قبلاً مستقرشده را به این روش‌ها حذف کنید:

  • به‌طور صریح در Firebase CLI با functions:delete
  • صراحتاً در کنسول Google Cloud.
  • به‌طور ضمنی با برداشتن تابع از منبع قبل‌از استقرار.

همه عملیات حذف از شما می‌خواهند قبل‌از برداشتن تابع از تولید، تأیید کنید.

حذف صریح تابع در Firebase CLI از چند آرگومان و همچنین گروه‌های تابع پشتیبانی می‌کند و به شما امکان می‌دهد تابعی را که در منطقه خاصی اجرا می‌شود مشخص کنید. همچنین می‌توانید پیام‌واره تأیید را لغو کنید.

  • همه توابعی را که با نام مشخص‌شده در همه مناطق مطابقت دارند حذف می‌کند: 

    firebase functions:delete FUNCTION-1_NAME

  • تابع مشخصی را که در منطقه‌ای غیراز منطقه پیش‌فرض اجرا می‌شود حذف می‌کند: 

    firebase functions:delete FUNCTION-1_NAME --region REGION_NAME

  • بیش‌از یک تابع را حذف می‌کند: 

    firebase functions:delete FUNCTION-1_NAME FUNCTION-2_NAME

  • گروه توابع مشخص‌شده را حذف می‌کند: 

    firebase functions:delete GROUP_NAME

  • پیام‌واره تأیید را دور می‌زند: 

    firebase functions:delete FUNCTION-1_NAME --force

با حذف ضمنی تابع، firebase deploy منبع شما را تجزیه می‌کند و هر تابعی را که از فایل برداشته شده است از تولید برمی‌دارد.

اصلاح نام، منطقه، یا راه‌انداز تابع

اگر درحال تغییر نام یا تغییر مناطق یا راه‌انداز برای عملکردهایی هستید که ترافیک تولید را مدیریت می‌کنند، مراحل این بخش را دنبال کنید تا از دست دادن رویدادها درطول اصلاح جلوگیری شود. قبل‌از دنبال کردن این مراحل، ابتدا مطمئن شوید که تابع شما idempotent است، زیرا هم نسخه جدید و هم نسخه قدیمی تابع شما به‌طور هم‌زمان درطول تغییر اجرا خواهند شد.

تغییر دادن نام تابع

برای تغییر نام تابع، نسخه جدیدی از تابع را با نام جدید در منبع خود ایجاد کنید و سپس دو فرمان استقرار جداگانه اجرا کنید. فرمان اول تابع جدیداً نام‌گذاری‌شده را مستقر می‌کند و فرمان دوم نسخه قبلاً مستقرشده را برمی‌دارد. برای مثال، اگر وب‌قلاب راه‌اندازی‌شده با HTTP دارید که می‌خواهید نام آن را تغییر دهید، کد را به‌صورت زیر اصلاح کنید:

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");
});

پایتون

# 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

تغییر دادن منطقه یا مناطق تابع

اگر مناطق مشخص‌شده را برای تابعی که ترافیک تولید را مدیریت می‌کند تغییر می‌دهید، می‌توانید با انجام این مراحل به‌ترتیب از، ازدست رفتن رویداد جلوگیری کنید:

  1. نام تابع را تغییر دهید و منطقه یا مناطق آن را به‌دلخواه تغییر دهید.
  2. تابع تغییرنام‌یافته را مستقر کنید که منجر به اجرای موقت کد یکسان در هر دو مجموعه منطقه می‌شود.
  3. تابع قبلی را حذف کنید.

برای مثال، اگر تابع راه‌اندازی‌شده با Cloud Firestore دارید که درحال‌حاضر در us-central1 مستقر شده است و می‌خواهید آن را به asia-northeast1 منتقل کنید، ابتدا باید کد منبع خود را تغییر دهید تا نام تابع را تغییر دهید و منطقه را بازبینی کنید.

Node.js

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

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

کد به‌روزشده باید فیلتر رویداد صحیح (در این مورد document) را به‌همراه منطقه مشخص کند. برای اطلاعات بیشتر، Cloud Functions مکان را ببینید.

پایتون

# 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 وجود ندارد. برای جلوگیری از خطا، نوع راه‌انداز تابع را با این روش تغییر دهید:

  1. کد منبع را تغییر دهید تا تابع جدیدی با نوع راه‌انداز دلخواه اضافه شود.
  2. تابع را مستقر کنید، که منجر به اجرای موقت هر دو تابع قدیمی و جدید می‌شود.
  3. تابع قدیمی را بااستفاده از Firebase CLI به‌طور صریح از تولید حذف کنید.

برای مثال، اگر تابعی داشتید که هنگام حذف شدن شیء راه‌اندازی می‌شد، اما سپس نسخه‌بندی شیء را فعال کردید و می‌خواهید به‌جای آن در رویداد بایگانی مشترک شوید، ابتدا نام تابع را تغییر دهید و آن را ویرایش کنید تا نوع راه‌انداز جدید را داشته باشد.

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) => {
    // ...
});

پایتون

# 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 گزینه‌های زمان اجرا را که در کدتان تنظیم شده است با تنظیمات نسخه فعلی تابع شما که مستقر شده است با اولویت زیر ادغام می‌کند:

  1. گزینه در کد توابع تنظیم شده است: تغییرات خارجی لغو شود.
  2. گزینه در کد توابع روی RESET_VALUE تنظیم شده است: تغییرات خارجی را با مقدار پیش‌فرض لغو کنید.
  3. گزینه در کد توابع تنظیم نشده است، اما در تابع مستقرشده فعلی تنظیم شده است: از گزینه مشخص‌شده در تابع مستقرشده استفاده کنید.

استفاده از گزینه preserveExternalChanges: true برای اکثر سناریوها توصیه نمی‌شود زیرا کد شما دیگر منبع کامل حقیقت برای گزینه‌های زمان اجرا برای توابع شما نخواهد بود. اگر از آن استفاده می‌کنید، کنسول Google Cloud را بررسی کنید یا از gcloud CLI برای مشاهده پیکربندی کامل تابع استفاده کنید.

تنظیم نسخه Node.js

Firebase SDK برای Cloud Functions امکان انتخاب زمان اجرای Node.js را فراهم می‌کند. می‌توانید انتخاب کنید که همه توابع در یک پروژه منحصراً در محیط زمان اجرا مربوط به یکی از این نسخه‌های Node.js پشتیبانی‌شده اجرا شوند:

  • Node.js 22
  • Node.js 20
  • Node.js 18 (منسوخ‌شده)

نسخه‌های ۱۴ و ۱۶ Node.js در اوایل سال ۲۰۲۵ از رده خارج شدند. استقرار با این نسخه‌ها غیرفعال است. برای اطلاعات مهم درباره پشتیبانی مداوم از این نسخه‌های Node.js، برنامه پشتیبانی را ببینید.

برای تنظیم کردن نسخه Node.js:

می‌توانید نسخه را در فیلد engines در فایل package.json که درطول مقداردهی اولیه در دایرکتوری functions/ شما ایجاد شده است تنظیم کنید. برای مثال، برای استفاده از نسخه ۲۰، این خط را در package.json ویرایش کنید:

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

اگر از مدیر بسته Yarn استفاده می‌کنید یا الزامات خاص دیگری برای فیلد engines دارید، می‌توانید زمان اجرا را برای کیت توسعه نرم‌افزار Firebase برای Cloud Functions در firebase.json تنظیم کنید:

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

CLI از مقدار تنظیم‌شده در firebase.json به‌جای هر مقدار یا محدوده‌ای که به‌طور جداگانه در package.json تنظیم کرده‌اید استفاده می‌کند.

ارتقا دادن زمان اجرای Node.js

برای ارتقا دادن زمان اجرای Node.js:

  1. مطمئن شوید پروژه‌تان در طرح قیمت‌گذاری Blaze باشد.
  2. مطمئن شوید از Firebase CLI نسخه ۱۱.۱۸.۰ یا جدیدتر استفاده می‌کنید.
  3. مقدار engines را در فایل package.json که درطول مقداردهی اولیه در فهرست راهنمای functions/ شما ایجاد شده است تغییر دهید. برای مثال، اگر از نسخه ۱۸ به نسخه ۲۰ ارتقا می‌دهید، ورودی باید به‌این‌صورت باشد: "engines": {"node": "20"}
  4. درصورت تمایل، تغییراتتان را بااستفاده از Firebase Local Emulator Suite آزمایش کنید.
  5. همه توابع را دوباره مستقر کنید.

انتخاب سیستم ماژول Node.js

سیستم ماژول پیش‌فرض در Node.js،‏ CommonJS (CJS) است، اما نسخه‌های فعلی Node.js از «ماژول‌های ECMAScript»‏ (ESM) نیز پشتیبانی می‌کنند. ‫Cloud Functions از هر دو پشتیبانی می‌کند.

به‌طور پیش‌فرض، توابع شما از CommonJS استفاده می‌کنند. این یعنی واردات و صادرات به این شکل است:

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

exports.helloWorld = onRequest(async (req, res) => res.send("Hello from Firebase!"));

برای استفاده از ESM، فیلد "type": "module" را در فایل package.json تنظیم کنید :

  {
   ...
   "type": "module",
   ...
  }

وقتی این را تنظیم کردید، از نحو ESM import و export استفاده کنید:

import {onRequest} from "firebase-functions/https";

export const helloWorld = onRequest(async (req, res) => res.send("Hello from Firebase!"));

هر دو سیستم واحد به‌طور کامل پشتیبانی می‌شوند. می‌توانید هرکدام را که برای پروژه‌تان مناسب‌تر است انتخاب کنید. در اسناد Node.js درباره ماژول‌ها اطلاعات بیشتری کسب کنید.

تنظیم نسخه Python

Firebase SDK برای Cloud Functions نسخه‌های ۱۲.۰.۰ و بالاتر امکان انتخاب زمان اجرای Python را فراهم می‌کند. نسخه زمان اجرا را در 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 نسل دوم با Cloud Run ارائه می‌شود و از قوانین Cloud Run برای مقیاس‌بندی خودکار نمونه محفظه پیروی می‌کند.

هنگام آزمایش تنظیمات همزمانی بالاتر در Cloud Functions for Firebase (نسل دوم)، موارد زیر را درنظر داشته باشید:

  • تنظیمات همزمانی بالاتر ممکن است برای عملکرد بهینه به واحد پردازش مرکزی و RAM بالاتری نیاز داشته باشد تا به حد عملی برسد. برای مثال، تابعی که پردازش سنگین تصویر یا ویدیو انجام می‌دهد ممکن است منابع کافی برای رسیدگی به ۱۰۰۰ درخواست هم‌زمان را نداشته باشد، حتی اگر تنظیمات CPU و RAM آن در حداکثر مقدار باشد.
  • ازآنجایی‌که Cloud Functions for Firebase (نسل دوم) از Cloud Run پشتیبانی می‌کند، می‌توانید به راهنمای Google Cloud برای بهینه‌سازی همزمانی نیز مراجعه کنید.
  • حتماً قبل‌از رفتن به حالت چندهمزمانی در محیط تولید، چندهمزمانی را به‌طور کامل در محیط آزمایشی آزمایش کنید.

حداقل تعداد نمونه‌ها را گرم نگه دارید

می‌توانید حداقل تعداد نمونه‌ها را برای یک تابع در کد منبع تنظیم کنید. برای مثال، این تابع حداقل ۵ نمونه را برای گرم نگه داشتن تنظیم می‌کند:

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
  }
);

پایتون

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

هنگام تنظیم مقدار حداقل نمونه‌ها، موارد زیر را درنظر بگیرید:

  • اگر Cloud Functions for Firebase برنامه‌تان را فراتر از تنظیماتتان مقیاس‌بندی کند، برای هر نمونه فراتر از آن آستانه، شروع سرد را تجربه خواهید کرد.
  • شروع سرد شدیدترین تأثیر را بر برنامه‌هایی دارد که ترافیک جهشی دارند. اگر برنامه‌تان ترافیک جهشی دارد و مقداری را تنظیم کنید که به‌اندازه کافی بالا باشد تا راه‌اندازی‌های سرد در هر افزایش ترافیک کاهش یابد، شاهد کاهش قابل‌توجهی در تأخیر خواهید بود. برای برنامه‌هایی که ترافیک ثابت دارند، شروع سرد احتمالاً تأثیر شدیدی بر عملکرد ندارد.

  • تنظیم حداقل نمونه‌ها می‌تواند برای محیط‌های تولید منطقی باشد، اما معمولاً باید در محیط‌های آزمایشی از آن اجتناب شود. برای مقیاس‌بندی به صفر در پروژه آزمایشی‌تان اما همچنان کاهش شروع سرد در پروژه تولیدی‌تان، می‌توانید مقدار حداقل نمونه‌ها را در پیکربندی پارامتری‌شده خود تنظیم کنید:

    Node.js

    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.")

محدود کردن حداکثر تعداد نمونه‌ها برای تابع

می‌توانید مقداری را برای حداکثر نمونه‌ها در کد منبع تابع تنظیم کنید. برای مثال، این تابع محدودیت ۱۰۰ نمونه را تعیین می‌کند تا پایگاه داده قدیمی فرضی را تحت‌الشعاع قرار ندهد:

Node.js

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 تا حداکثر حد نمونه‌ها مقیاس‌بندی شود، درخواست‌های جدید به‌مدت ۳۰ ثانیه در صف قرار می‌گیرند و سپس با کد پاسخ 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 انجام دهید.

تنظیم مهلت و تخصیص حافظه

در برخی موارد، ممکن است توابع شما الزامات خاصی برای مقدار زمان‌اتمام طولانی یا تخصیص حافظه بزرگ داشته باشند. می‌توانید این مقادیر را در کنسول Google Cloud یا در کد منبع تابع (فقط Firebase) بااستفاده از مقادیر زمان اتمام در این محدوده‌های حداکثر مدت تنظیم کنید:

  • توابع HTTP و قابل‌فراخوانی: ۳۶۰۰ ثانیه (۶۰ دقیقه)
  • توابع صف وظیفه/زمان‌بندی‌شده: ۱۸۰۰ ثانیه (۳۰ دقیقه)
  • سایر توابع رویدادمحور: ۵۴۰ ثانیه (۹ دقیقه)

برای تنظیم تخصیص حافظه و زمان‌اتمام در کد منبع توابع، از گزینه‌های سراسری برای حافظه و ثانیه‌های زمان‌اتمام استفاده کنید تا ماشین مجازی اجراکننده توابع را سفارشی‌سازی کنید. برای مثال، این تابع Cloud Storage از ۱ گیگابایت حافظه استفاده می‌کند و پس‌از ۳۰۰ ثانیه منقضی می‌شود:

Node.js

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.

برای تنظیم تخصیص حافظه و مهلت اتمام در کنسول Google Cloud:

  1. در کنسول Google Cloud، Cloud Functions for Firebase را از منوِ سمت راست انتخاب کنید.
  2. با کلیک کردن روی نام تابع در فهرست توابع، آن را انتخاب کنید.
  3. روی نماد ویرایش در منو بالایی کلیک کنید.
  4. از منوِ کرکره‌ای با برچسب حافظه اختصاص‌داده‌شده، تخصیص حافظه را انتخاب کنید.
  5. روی بیشتر کلیک کنید تا گزینه‌های پیشرفته نمایش داده شود، و تعداد ثانیه‌ها را در چارگوش نوشتاری زمان اتمام وارد کنید.
  6. برای به‌روزرسانی تابع، روی ذخیره کلیک کنید.

ملغی کردن پیش‌فرض‌های واحد پردازش مرکزی

تا ۲ گیگابایت حافظه اختصاص داده شده است، هر تابع در Cloud Functions for Firebase (نسل دوم) به‌طور پیش‌فرض یک CPU دارد و سپس برای ۴ و ۸ گیگابایت به ۲ CPU افزایش می‌یابد. توجه داشته باشید که این رفتار تفاوت قابل‌توجهی با رفتار پیش‌فرض نسل اول دارد و می‌تواند منجر به هزینه‌های کمی بالاتر برای توابع با حافظه کم شود، همان‌طور که در جدول زیر نشان داده شده است:

حافظه دسترسی تصادفی اختصاص‌داده‌شده واحد پردازش مرکزی پیش‌فرض نسخه ۱ (کسری) واحد پردازش مرکزی پیش‌فرض نسخه ۲ افزایش قیمت به‌ازای هر میلی‌ثانیه
‫۱۲۸ مگابایت ‫۱/۱۲ 1 ‫۱۰٫۵ برابر
‫۲۵۶ مگابایت ‫۱/۶ 1 ‫۵٫۳ برابر
‫۵۱۲ مگابایت ‫۱/۳ 1 ‫۲٫۷ برابر
‫۱ گیگابایت ‫۷/۱۲ 1 ‫۱٫۶ برابر
‫۲ گیگابایت 1 1 ‫۱ برابر
۴ گیگابایت 2 2 ‫۱ برابر
‫۸ گیگابایت 2 2 ‫۱ برابر
‫۱۶ گیگابایت نامشخص 4 نامشخص

اگر رفتار نسل اول را برای عملکردهای نسل دوم ترجیح می‌دهید، پیش‌فرض‌های نسل اول را به‌عنوان گزینه سراسری تنظیم کنید:

Node.js

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

پایتون

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

برای عملکردهای با مصرف بالای CPU، نسل دوم انعطاف‌پذیری لازم را برای پیکربندی CPU اضافی فراهم می‌کند. می‌توانید واحد پردازش مرکزی را براساس هر تابع تقویت کنید، همان‌طور که نشان داده شده است:

Node.js

// 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