إدارة الدوال


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

دوال النشر

لتفعيل الوظائف، يمكنك تشغيل الأمر CLI في Firebase التالي:

firebase deploy --only functions

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

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

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

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

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

حذف الدوال

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

  • بشكل صريح في واجهة سطر الأوامر بمنصة 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 وتريد إعادة تسميته، راجِع الرمز على النحو التالي:

Node.js

// before
const {onRequest}  = require('firebase-functions/v2/https');

exports.webhook = onRequest((req, res) => {
    res.send("Hello");
});

// after
const {onRequest}  = require('firebase-functions/v2/https');

exports.webhookNew = onRequest((req, res) => {
    res.send("Hello");
});

Python

# before
from firebase_functions import https_fn

@https_fn.on_request()
def webhook(req: https_fn.Request) -> https_fn.Response:
    return https_fn.Response("Hello world!")

# after
from firebase_functions import https_fn

@https_fn.on_request()
def webhook_new(req: https_fn.Request) -> https_fn.Response:
    return https_fn.Response("Hello world!")

بعد ذلك، شغّل الأوامر التالية لنشر الدالة الجديدة:

# 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 للحصول على مزيد من المعلومات.

Python

# Before
@firestore_fn.on_document_created("my-collection/{docId}")
def firestore_trigger(event):
    pass

# After
@firestore_fn.on_document_created("my-collection/{docId}",
                                  region="asia-northeast1")
def firestore_trigger_asia(event):
    pass

بعد ذلك، يمكنك النشر من خلال التشغيل:

firebase deploy --only functions:firestoreTriggerAsia

هناك دالتان متطابقتان قيد التشغيل الآن: firestoreTrigger تعمل في us-central1 وfirestoreTriggerAsia في asia-northeast1.

بعد ذلك، يمكنك حذف firestoreTrigger:

firebase functions:delete firestoreTrigger

هناك دالة واحدة فقط الآن، وهي firestoreTriggerAsia، قيد التشغيل في asia-northeast1.

تغيير نوع مشغل الدالة

أثناء تطوير وظائف السحابة الإلكترونية لنشر Firebase بمرور الوقت، قد تحتاج إلى تغيير نوع مشغِّل الوظيفة لأسباب مختلفة. مثلاً، قد ترغب في التغيير من أحد أنواع "قاعدة بيانات Firebase في الوقت الفعلي" أو حدث Cloud Firestore إلى نوع آخر.

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

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

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

Node.js

// before
const {onObjectDeleted} = require("firebase-functions/v2/storage");

exports.objectDeleted = onObjectDeleted((event) => {
    // ...
});

// after
const {onObjectArchived} = require("firebase-functions/v2/storage");

exports.objectArchived = onObjectArchived((event) => {
    // ...
});

Python

# before
from firebase_functions import storage_fn

@storage_fn.on_object_deleted()
def object_deleted(event):
  # ...

# after 
from firebase_functions import storage_fn

@storage_fn.on_object_archived()
def object_archived(event):
  # ...

بعد ذلك، شغِّل الأوامر التالية لإنشاء الدالة الجديدة أولاً، قبل حذف الدالة القديمة:

# 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 في 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 أو استخدِم gcloud CLI لعرض الإعدادات الكاملة للدالة.

ضبط إصدار Node.js

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

  • Node.js 22 (معاينة)
  • Node.js 20
  • Node.js 18

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

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

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

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

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

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

يستخدم واجهة سطر الأوامر القيمة التي تم تحديدها في 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.
  5. إعادة نشر جميع الدوال.

ضبط إصدار Python

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

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

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

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

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

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

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

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

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

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

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

يوضح هذا السيناريو المبسّط مكاسب الكفاءة المحتملة الناتجة عن التزامن. في الواقع، يكون توسيع نطاق السلوك لتحسين الكفاءة وتقليل البداية الباردة بالتزامن أكثر تعقيدًا. يستند التزامن في وظائف السحابة الإلكترونية لبرنامج Firebase للجيل الثاني من Cloud Run، ويتبع قواعد Cloud Run المتعلقة بالقياس التلقائي لمثيل الحاوية.

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

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

الحفاظ على حرارة الحد الأدنى من الحالات

يمكنك تحديد الحد الأدنى لعدد الحالات لدالة في رمز المصدر. على سبيل المثال، تحدد هذه الدالة ما لا يقل عن 5 مثيلات للحفاظ على الحرارة:

Node.js

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

exports.getAutocompleteResponse = onCall(
  {
    // Keep 5 instances warm for this latency-critical function
    minInstances: 5,
  },
  (event) => {
    // Autocomplete user’s search term
  }
);

Python

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

إليك بعض الأمور التي يجب مراعاتها عند ضبط الحد الأدنى لقيمة المثيلات:

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

    Node.js

    const functions = require('firebase-functions');
    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 مثيل حتى لا تربك قاعدة بيانات افتراضية قديمة:

Node.js

const { onMessagePublished } = require("firebase-functions/v2/pubsub");

exports.mirrorevents = onMessagePublished(
  { topic: "topic-name", maxInstances: 100 },
  (event) => {
    // Connect to legacy database
  }
);

Python

@pubsub_fn.on_message_published(topic="topic-name", max_instances=100)
def mirrorevents(event: pubsub_fn.CloudEvent):
#  Connect to legacy database

في حال زيادة الحد الأقصى المسموح به لعدد المثيلات في دالة HTTP، تتم إضافة الطلبات الجديدة إلى قائمة الانتظار لمدة 30 ثانية، ثم يتم رفضها باستخدام رمز الاستجابة 429 Too Many Requests، وذلك في حال عدم توفّر أي مثيل بحلول ذلك الوقت.

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

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

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

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

Node.js

exports.convertLargeFile = onObjectFinalized({
  timeoutSeconds: 300,
  memory: "1GiB",
}, (event) => {
  // Do some complicated things that take a lot of memory and time
});

Python

@storage_fn.on_object_finalized(timeout_sec=300, memory=options.MemoryOption.GB_1)
def convert_large_file(event: storage_fn.CloudEvent):
# Do some complicated things that take a lot of memory and time.

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

لضبط تخصيص الذاكرة والمهلة في Google Cloud Console:

  1. في وحدة التحكّم في Google Cloud، اختَر وظائف السحابة الإلكترونية لبرنامج Firebase من القائمة اليمنى.
  2. حدد دالة عن طريق النقر فوق اسمها في قائمة الدوال.
  3. انقر على رمز تعديل في القائمة العلوية.
  4. اختَر أحد التخصيصات للذاكرة من القائمة المنسدلة بعنوان الذاكرة المخصصة.
  5. انقر على المزيد لعرض الخيارات المتقدمة، وأدخل عدد الثواني في مربع نص المهلة.
  6. انقر على حفظ لتعديل الدالة.

إلغاء الإعدادات التلقائية لوحدة المعالجة المركزية (CPU)

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

تم تخصيص ذاكرة الوصول العشوائي (RAM) وحدة المعالجة المركزية التلقائية في الإصدار 1 (كسرية) وحدة المعالجة المركزية التلقائية للإصدار 2 الزيادة في السعر لكل ملي ثانية
128 ميغابايت 1/12 1 10.5 مرات
256 ميغابايت 6/1 1 أسرع بـ 5,3 مرات
512 ميغابايت 3/1 1 أسرع بـ 2.7 مرة
1 غيغابايت 12/7 1 أسرع بـ 1,6 مرات
2 غيغابايت 1 1 1x
4 غيغابايت 2 2 1x
8 غيغابايت 2 2 1x
16 غيغابايت timing fixed in amara 4 timing fixed in amara

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

Node.js

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

Python

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

Python

# Boost CPU in a function:
@storage_fn.on_object_finalized(cpu=2)
def analyze_image(event: storage_fn.CloudEvent):
# computer vision goes here