إدارة الوظائف

يمكنك نشر الدوال وحذفها وتعديلها باستخدام أوامر واجهة سطر الأوامر (CLI) في Firebase أو من خلال ضبط خيارات وقت التشغيل في الرمز المصدر للدوال.

نشر الدوال

لنشر الدوال، نفِّذ أمر واجهة سطر الأوامر (CLI) التالي في Firebase:

firebase deploy --only functions

تلقائيًا، تنشر واجهة سطر الأوامر في Firebase جميع الدوال داخل المصدر في الوقت نفسه. إذا كان مشروعك يحتوي على أكثر من 5 دوال، ننصحك باستخدام العلامة --only مع أسماء دوال محدّدة لنشر الدوال التي عدّلتها فقط. يؤدي نشر دوال معيّنة بهذه الطريقة إلى تسريع عملية النشر ويساعدك على تجنّب تجاوز الحصص المخصصة للنشر. على سبيل المثال:

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

عند نشر عدد كبير من الدوال، قد تتجاوز الحصة العادية وتتلقّى رسائل خطأ HTTP 429 أو 500. لحلّ هذه المشكلة، يمكنك نشر الدوال في مجموعات من 10 دوال أو أقل.

يمكنك الاطّلاع على مرجع واجهة سطر أوامر Firebase للحصول على القائمة الكاملة للأوامر المتاحة.

يبحث واجهة سطر الأوامر في Firebase تلقائيًا في المجلد functions/ عن الرمز المصدر. يمكنك تنظيم الدوال في قواعد الرموز البرمجية أو مجموعات متعددة من الملفات إذا أردت.

حذف عناصر النشر

كجزء من عملية نشر الدوال، يتم إنشاء صور الحاويات وتخزينها في Artifact Registry. هذه الصور ليست مطلوبة لتشغيل الدوال المنشورة، إذ يجلب Cloud Functions نسخة من الصورة ويحتفظ بها عند النشر الأولي، ولكن العناصر المخزّنة ليست ضرورية لعمل الدالة في وقت التشغيل.

على الرغم من أنّ صور الحاويات هذه غالبًا ما تكون صغيرة، إلا أنّها يمكن أن تتراكم بمرور الوقت وتساهم في زيادة تكاليف التخزين. قد تفضّل الاحتفاظ بها لفترة من الوقت إذا كنت تخطّط لفحص العناصر التي تم إنشاؤها أو إجراء عمليات فحص لثغرات الحاويات.

للمساعدة في إدارة تكاليف مساحة التخزين، يتيح لك الإصدار 14.0.0 من واجهة سطر الأوامر (CLI) في Firebase والإصدارات الأحدث ضبط سياسة تنظيف 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 من إعداد سياسة تنظيف بعد نشر الدوال.

حذف الدوال

يمكنك حذف الدوال التي تم نشرها سابقًا بالطرق التالية:

• بشكل صريح في واجهة سطر الأوامر (CLI) في Firebase باستخدام functions:delete
• بشكل صريح في وحدة تحكّم Google Cloud.
• ضمنيًا عن طريق إزالة الدالة من المصدر قبل النشر

تطلب منك جميع عمليات الحذف التأكيد قبل إزالة الدالة من مرحلة الإنتاج.

يتيح حذف الدوال الصريحة في واجهة سطر الأوامر (CLI) في Firebase استخدام وسيطات متعددة بالإضافة إلى مجموعات الدوال، ويسمح لك بتحديد دالة تعمل في منطقة معيّنة. يمكنك أيضًا إلغاء طلب التأكيد.

• يحذف هذا الأمر جميع الدوال التي تتطابق مع الاسم المحدّد في جميع المناطق:

  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 المصدر ويزيل من الإنتاج أي دوال تمت إزالتها من الملف.

تعديل اسم دالة أو منطقتها أو عامل تشغيلها

إذا كنت بصدد إعادة تسمية أو تغيير المناطق أو المشغّلات للدوال التي تتعامل مع زيارات الإنتاج، اتّبِع الخطوات الواردة في هذا القسم لتجنُّب فقدان الأحداث أثناء التعديل. قبل اتّباع هذه الخطوات، تأكَّد أولاً من أنّ الدالة متكررة، لأنّ كلاً من الإصدار الجديد والإصدار القديم من الدالة سيعملان في الوقت نفسه أثناء التغيير.

إعادة تسمية دالة

لإعادة تسمية دالة، أنشئ نسخة جديدة من الدالة في المصدر باسم جديد، ثم نفِّذ أمرَي نشر منفصلَين. ينشر الأمر الأول الدالة المُسمّاة حديثًا، ويزيل الأمر الثاني الإصدار الذي تم نشره سابقًا. على سبيل المثال، إذا كان لديك ويب هوك يتم تشغيله عبر 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

تغيير منطقة أو مناطق دالة

إذا كنت بصدد تغيير المناطق المحدّدة لدالة تعالج زيارات الإنتاج، يمكنك منع فقدان الأحداث من خلال تنفيذ هذه الخطوات بالترتيب:

1. أعِد تسمية الدالة وغيِّر منطقتها أو مناطقها حسب رغبتك.
2. انشر الدالة التي تمت إعادة تسميتها، ما يؤدي إلى تشغيل الرمز نفسه مؤقتًا في مجموعتَي المناطق.
3. احذف الدالة السابقة.

على سبيل المثال، إذا كانت لديك دالة يتم تشغيلها من خلال Cloud Firestore ويتم نشرها حاليًا في us-central1، وأردت نقلها إلى asia-northeast1، عليك أولاً تعديل الرمز المصدر لإعادة تسمية الدالة ومراجعة المنطقة.

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

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

# 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.

على سبيل المثال، إذا كانت لديك دالة يتم تشغيلها عند حذف كائن، ولكنك قمت بعد ذلك بتمكين إصدار الكائن وترغب في الاشتراك في حدث الأرشفة بدلاً من ذلك، فقم أولاً بإعادة تسمية الدالة وتحريرها للحصول على نوع المشغل الجديد.

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

تتيح حزمة تطوير البرامج (SDK) لـ Firebase في Cloud Functions اختيار بيئة تشغيل Node.js. يمكنك اختيار تشغيل جميع الدوال في مشروع حصريًا في بيئة التشغيل المتوافقة مع أحد إصدارات Node.js المتوافقة التالية:

• Node.js 22
• Node.js 20
• ‫Node.js 18 (متوقّفة نهائيًا)

تم إيقاف الإصدارَين 14 و16 من Node.js نهائيًا في أوائل عام 2025. تم إيقاف النشر باستخدام هذه الإصدارات. يُرجى الاطّلاع على جدول الدعم للحصول على معلومات مهمة بشأن الدعم المستمر لإصدارات Node.js هذه.

لضبط إصدار Node.js:

يمكنك ضبط الإصدار في حقل engines في ملف package.json الذي تم إنشاؤه في دليل functions/ أثناء الإعداد. على سبيل المثال، لاستخدام الإصدار 20 فقط، عدِّل هذا السطر في package.json:

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

إذا كنت تستخدم أداة إدارة الحِزم Yarn أو لديك متطلبات أخرى محدّدة لحقل engines، يمكنك ضبط بيئة التشغيل لحزمة تطوير البرامج (SDK) لـ Firebase في Cloud Functions في firebase.json بدلاً من ذلك:

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

تستخدم واجهة سطر الأوامر القيمة المحدّدة في firebase.json بدلاً من أي قيمة أو نطاق تحدّده بشكل منفصل في package.json.

ترقية بيئة التشغيل Node.js

لترقية بيئة التشغيل Node.js، اتّبِع الخطوات التالية:

1. تأكَّد من أنّ مشروعك يستخدم خطة Blaze المَرِنة.
2. تأكَّد من استخدام الإصدار 11.18.0 أو إصدار أحدث من واجهة سطر الأوامر في Firebase.
3. غيِّر قيمة engines في ملف package.json الذي تم إنشاؤه في دليل functions/ أثناء الإعداد. على سبيل المثال، إذا كنت تُجري ترقية من الإصدار 18 إلى الإصدار 20، يجب أن يظهر الإدخال على النحو التالي: "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

تتيح حزمة تطوير البرامج (SDK) لـ "Firebase" في الإصدارات 12.0.0 من "Cloud Functions" والإصدارات الأحدث اختيار بيئة تشغيل Python. اضبط إصدار بيئة التشغيل في firebase.json كما هو موضّح:

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

التحكّم في سلوك تغيير الحجم

بشكل تلقائي، يغيّر Cloud Functions for Firebase عدد المثيلات قيد التشغيل بناءً على عدد الطلبات الواردة، وقد يصل إلى الصفر في أوقات انخفاض عدد الزيارات. ومع ذلك، إذا كان تطبيقك يتطلّب تقليل وقت الاستجابة وأردت الحدّ من عدد عمليات بدء التشغيل على البارد، يمكنك تغيير هذا الإعداد التلقائي من خلال تحديد الحدّ الأدنى لعدد نُسخ الحاويات التي يجب أن تظل نشطة وجاهزة لعرض الطلبات.

وبالمثل، يمكنك ضبط حدّ أقصى لعدد المثيلات استجابةً للطلبات الواردة. استخدِم هذا الإعداد للتحكّم في التكاليف أو للحدّ من عدد الاتصالات بخدمة احتياطية، مثل قاعدة بيانات.

باستخدام هذه الإعدادات مع إعداد التزامن لكل مثيل (جديد في الجيل الثاني)، يمكنك التحكّم في سلوك التوسّع لوظائفك وضبطه. ستحدد طبيعة تطبيقك ووظيفته الإعدادات الأكثر فعالية من حيث التكلفة والتي ستؤدي إلى أفضل أداء.

بالنسبة إلى بعض التطبيقات التي تسجّل عددًا قليلاً من الزيارات، يُعدّ خيار وحدة المعالجة المركزية (CPU) الأقل بدون التزامن المتعدّد هو الخيار الأمثل. بالنسبة إلى التطبيقات الأخرى التي تمثّل فيها البدايات الباردة مشكلة خطيرة، يعني ضبط عدد كبير من الطلبات المتزامنة والحد الأدنى من المثيلات أنّ مجموعة من المثيلات تظل دائمًا جاهزة للتعامل مع الارتفاعات الكبيرة في عدد الزيارات.

بالنسبة إلى التطبيقات الأصغر حجمًا التي تتلقّى عددًا قليلاً جدًا من الزيارات، فإنّ ضبط الحد الأقصى لعدد المثيلات على قيمة منخفضة مع قيمة عالية لعدد الطلبات المتزامنة يعني أنّ التطبيق يمكنه التعامل مع الزيارات المفاجئة بدون تكبّد تكاليف زائدة. ومع ذلك، ضع في اعتبارك أنه عند تعيين الحد الأقصى لعدد المثيلات على قيمة منخفضة للغاية، قد يتم إسقاط الطلبات عند الوصول إلى الحد الأقصى.

السماح بالطلبات المتزامنة

في Cloud Functions for Firebase (الجيل الأول)، كان بإمكان كل مثيل معالجة طلب واحد في كل مرة، لذلك تم ضبط سلوك التوسيع فقط من خلال إعدادات الحد الأدنى والحد الأقصى للمثيلات. بالإضافة إلى التحكّم في عدد النُسخ، يمكنك في Cloud Functions for Firebase (الجيل الثاني) التحكّم في عدد الطلبات التي يمكن لكل نسخة عرضها في الوقت نفسه باستخدام الخيار concurrency. القيمة التلقائية للتزامن هي 80، ولكن يمكنك ضبطها على أي عدد صحيح بين 1 و1000.

يمكن للدوال التي تتضمّن إعدادات تزامن أعلى استيعاب الارتفاعات المفاجئة في عدد الزيارات بدون بدء التشغيل على البارد لأنّ كل مثيل من المحتمل أن يكون لديه بعض المساحة الإضافية. إذا تم ضبط مثيل لمعالجة ما يصل إلى 50 طلبًا متزامنًا، ولكنه يعالج حاليًا 25 طلبًا فقط، يمكنه معالجة زيادة مفاجئة في عدد الطلبات بمقدار 25 طلبًا إضافيًا بدون الحاجة إلى بدء تشغيل مثيل جديد. في المقابل، إذا كان إعداد التزامن هو 1 فقط، قد يؤدي هذا الارتفاع في الطلبات إلى 25 عملية تشغيل بارد.

يوضح هذا السيناريو المبسط المكاسب المحتملة في الكفاءة من التزامن. في الواقع، إنّ سلوك التوسّع لتحسين الكفاءة وتقليل عمليات التشغيل على البارد باستخدام التزامن هو أكثر تعقيدًا. تعتمد ميزة التزامن في الجيل الثاني من "Cloud Functions for Firebase" على "Cloud Run"، وتتّبع قواعد "Cloud Run" المتعلّقة بـ التوسيع التلقائي لمثيلات الحاويات.

عند تجربة إعدادات التزامن الأعلى في Cloud Functions for Firebase (الجيل الثاني)، يجب مراعاة ما يلي:

• قد تتطلّب إعدادات التزامن الأعلى استخدامًا أكبر لوحدة المعالجة المركزية وذاكرة الوصول العشوائي لتحقيق الأداء الأمثل إلى أن يتم الوصول إلى حدّ عملي. على سبيل المثال، قد تفتقر الدالة التي تعالج الصور أو الفيديوهات بشكل مكثّف إلى الموارد اللازمة للتعامل مع 1,000 طلب متزامن، حتى عند ضبط إعدادات وحدة المعالجة المركزية وذاكرة الوصول العشوائي على الحد الأقصى.
• بما أنّ Cloud Functions for Firebase (الجيل الثاني) يستند إلى Cloud Run، يمكنك أيضًا الرجوع إلى إرشادات Google Cloud بشأن تحسين التزامن.
• احرص على اختبار ميزة "التزامن المتعدّد" بدقة في بيئة اختبار قبل التبديل إلى هذه الميزة في مرحلة الإنتاج.

الاحتفاظ بالحدّ الأدنى من المثيلات في وضع الاستعداد

يمكنك ضبط الحدّ الأدنى لعدد النُسخ لدالة في الرمز المصدر. على سبيل المثال، تضبط هذه الدالة الحد الأدنى لعدد النُسخ التي يجب إبقاؤها جاهزة على 5:

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

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

الحدّ من الحدّ الأقصى لعدد النُسخ لدالة معيّنة

يمكنك ضبط قيمة للحدّ الأقصى لعدد النُسخ في الرمز المصدر للدالة. على سبيل المثال، تضع هذه الدالة حدًا أقصى يبلغ 100 مثيل لكي لا تتجاوز الحد الأقصى لقاعدة بيانات قديمة افتراضية:

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.

ضبط المهلة وتخصيص الذاكرة

في بعض الحالات، قد تتطلّب دوالّك متطلبات خاصة لقيمة مهلة طويلة أو تخصيص كبير للذاكرة. يمكنك ضبط هذه القيم إما في وحدة تحكّم Google Cloud أو في الرمز المصدر للدالة (Firebase فقط)، وذلك باستخدام قيم المهلة ضمن حدود المدة القصوى التالية:

• دوال HTTP والدوال القابلة للاستدعاء: 3600 ثانية (60 دقيقة)
• دوال قائمة انتظار المهام/المجدوَلة: 1800 ثانية (30 دقيقة)
• الدوال الأخرى المستندة إلى الأحداث: 540 ثانية (9 دقائق)

لضبط تخصيص الذاكرة والمهلة في الرمز المصدر للدوال، استخدِم الخيارات العامة للذاكرة وثواني المهلة لتخصيص الجهاز الافتراضي الذي يشغّل الدوال. على سبيل المثال، تستخدم دالة Cloud Storage هذه 1 غيغابايت من الذاكرة وتنتهي مهلتها بعد 300 ثانية:

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. انقر على حفظ لتعديل الدالة.

تجاوز الإعدادات التلقائية لوحدة المعالجة المركزية

يتم تخصيص ما يصل إلى 2 غيغابايت من الذاكرة، وتستخدم كل دالة في Cloud Functions for Firebase (الجيل الثاني) وحدة معالجة مركزية واحدة تلقائيًا، ثم تزيد إلى وحدتَي معالجة مركزية مقابل 4 و8 غيغابايت. يُرجى العِلم أنّ هذا يختلف بشكل كبير عن الإعداد التلقائي للجيل الأول بطرق قد تؤدي إلى تكاليف أعلى قليلاً للدوال ذات الذاكرة المنخفضة كما هو موضّح في الجدول التالي:

إذا كنت تفضّل سلوك الجيل الأول لدوال الجيل الثاني، يمكنك ضبط الإعدادات التلقائية للجيل الأول كخيار عام:

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

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

بالنسبة إلى الدوال التي تستهلك قدرًا كبيرًا من طاقة وحدة المعالجة المركزية، يوفّر الجيل الثاني المرونة اللازمة لضبط وحدة معالجة مركزية إضافية. يمكنك تعزيز وحدة المعالجة المركزية لكل دالة على حدة كما هو موضّح:

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