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

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

دوال النشر

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

firebase deploy --only functions

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

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

عند نشر أعداد كبيرة من الدوال، قد تتجاوز حصة معيارية وتلقى رسائل خطأ HTTP 429 أو 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 المصدر إزالة أي وظائف تمت إزالتها من الملف من الإنتاج.

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

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

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

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

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

أثناء تطوير "وظائف السحابة الإلكترونية لبرنامج Firebase" بمرور الوقت، يمكنك بحاجة إلى تغيير نوع مشغل الدالة لأسباب مختلفة. على سبيل المثال: فقد ترغب في التغيير من نوع واحد من قاعدة بيانات Firebase في الوقت الفعلي أو حدث 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

ضبط خيارات بيئة التشغيل

تتيح لك وظائف السحابة الإلكترونية لبرنامج 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 أو استخدِم واجهة سطر الأوامر لعرض التهيئة الكاملة للدالة.

ضبط إصدار 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، يمكنك ضبط وقت تشغيل حزمة تطوير البرامج (SDK) لمنصّة Firebase 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 لبرنامج Firebase (الجيل الأول)، يمكن لكل مثيل معالجة طلب واحد في كل مرة، وبالتالي تم تعيين سلوك التوسعة فقط باستخدام إعدادات الحد الأدنى والحد الأقصى للمثيلات. بالإضافة إلى التحكّم في عدد الحالات، يمكنك استخدام ميزات Cloud Functions في Firebase (الجيل الثاني) التحكم في عدد الطلبات التي يمكن لكل مثيل تقديمها في نفس الوقت باستخدام الخيار concurrency. القيمة التلقائية للتزامن هي 80، ولكن يمكنك اضبطه على أي عدد صحيح بين 1 و1000.

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

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

عند تجربة إعدادات تزامن أعلى في وظائف السحابة الإلكترونية لبرنامج Firebase (الجيل الثاني)، يجب أخذ ما يلي في الاعتبار:

• قد تتطلب إعدادات التزامن الأعلى توفير وحدة معالجة مركزية (CPU) وذاكرة وصول عشوائي (RAM) أعلى للحصول على أفضل النتائج. الأداء إلى أن تصل إلى حد عملي. دالة تقوم بمهمة مثلاً، قد تفتقر معالجة الصور أو الفيديوهات إلى الموارد اللازمة 1, 000 طلب متزامن، حتى عند زيادة إعدادات وحدة المعالجة المركزية (CPU) وذاكرة الوصول العشوائي (RAM) إلى أقصى حد
• بما أنّ ميزات Cloud Functions في 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 في 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 مثيل لكي لا إرباك قاعدة بيانات افتراضية قديمة:

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 Console أو في رمز المصدر الخاص بالدالة (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 Console:

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

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

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

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

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