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

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

نشر الوظائف

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

firebase deploy --only functions

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

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

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

راجع مرجع Firebase CLI للحصول على القائمة الكاملة للأوامر المتاحة.

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

حذف الوظائف

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

• بشكل صريح في Firebase CLI مع 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 لنشر Firebase بمرور الوقت، قد تحتاج إلى تغيير نوع تشغيل الوظيفة لأسباب مختلفة. على سبيل المثال، قد ترغب في التغيير من نوع واحد من أحداث Firebase Realtime Database أو Cloud Firestore إلى نوع آخر.

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

1. قم بتعديل الكود المصدري ليشمل وظيفة جديدة بنوع المشغل المطلوب.
2. نشر الوظيفة، مما يؤدي إلى تشغيل كل من الوظائف القديمة والجديدة مؤقتًا.
3. احذف الوظيفة القديمة بشكل صريح من الإنتاج باستخدام Firebase CLI.

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

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

قم بتعيين إصدار Node.js

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

• Node.js 20 (معاينة)
• نود.جي إس 18
• نود.جي إس 16
• نود.جي إس 14

لتعيين إصدار Node.js:

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

  "engines": {"node": "18"}

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

  {
    "functions": {
      "runtime": "nodejs18" // or nodejs14, nodejs16 or nodejs20
    }
  }

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

قم بترقية وقت تشغيل Node.js الخاص بك

لترقية وقت تشغيل Node.js الخاص بك:

1. تأكد من أن مشروعك مدرج في خطة تسعير Blaze .
2. تأكد من أنك تستخدم الإصدار 11.18.0 من Firebase CLI أو الإصدارات الأحدث.
3. قم بتغيير قيمة engines في ملف package.json الذي تم إنشاؤه في دليل functions/ الخاص بك أثناء التهيئة. على سبيل المثال، إذا كنت تقوم بالترقية من الإصدار 16 إلى الإصدار 18، فيجب أن يبدو الإدخال كما يلي: "engines": {"node": "18"}
4. اختياريًا، اختبر تغييراتك باستخدام Firebase Local Emulator Suite .
5. إعادة توزيع جميع الوظائف.

تعيين نسخة بايثون

تسمح إصدارات Firebase SDK for Cloud Functions 12.0.0 والإصدارات الأحدث باختيار وقت تشغيل Python. قم بتعيين إصدار وقت التشغيل في firebase.json كما هو موضح:

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

التحكم في سلوك القياس

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

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

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

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

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

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

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

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

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

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

• قد تتطلب إعدادات التزامن الأعلى وحدة معالجة مركزية وذاكرة وصول عشوائي أعلى للحصول على الأداء الأمثل حتى الوصول إلى الحد العملي. على سبيل المثال، قد تفتقر الوظيفة التي تقوم بمعالجة كثيفة للصور أو الفيديو إلى الموارد اللازمة للتعامل مع 1000 طلب متزامن، حتى عند زيادة إعدادات وحدة المعالجة المركزية (CPU) وذاكرة الوصول العشوائي (RAM) الخاصة بها.
• نظرًا لأن 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');
  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.`);
    }
  );
  

  بايثون

  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. انقر فوق المزيد لعرض الخيارات المتقدمة، وأدخل عدد الثواني في مربع النص Timeout .
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