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

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

نشر الدوال

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

firebase deploy --only functions

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

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

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

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

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

تنظيف عناصر النشر

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

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

للمساعدة في إدارة تكاليف التخزين، يتيح لك الإصدار 14.0.0 من 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 من إعداد سياسة تنظيف بعد عمليات نشر الدوال.

حذف الدوال

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

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

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

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

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

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

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

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

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

1. يتم ضبط الخيار في رمز الدوال: إلغاء التغييرات الخارجية.
2. تم ضبط الخيار على RESET_VALUE في رمز الدوال: يتم تجاهل التغييرات الخارجية واستخدام القيمة التلقائية.
3. لم يتم ضبط الخيار في رمز الدوال، ولكن تم ضبطه في الدالة التي تم نشرها حاليًا: استخدِم الخيار المحدّد في الدالة التي تم نشرها.

لا يُنصح باستخدام الخيار preserveExternalChanges: true في معظم الحالات لأنّ الرمز البرمجي لن يكون المصدر الكامل للمعلومات الصحيحة بشأن خيارات وقت التشغيل للدوال. في حال استخدامها، يمكنك الاطّلاع على الإعدادات الكاملة للدالة من خلال Google Cloud Console أو 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. أعِد نشر جميع الدوال.

ضبط إصدار 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 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.")
  

الحدّ من الحدّ الأقصى لعدد مثيلات الدالة

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

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

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

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

لضبط تخصيص الذاكرة والمهلة في الرمز المصدر للدوال، استخدِم الخيارات العامة للذاكرة وعدد ثواني المهلة لتخصيص الجهاز الافتراضي الذي يشغّل الدوال. على سبيل المثال، تستخدم الدالة 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.

الحدّ الأقصى لعدد ثواني المهلة هو 540، أو 9 دقائق.

لضبط تخصيص الذاكرة والمهلة في وحدة تحكّم 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