يمكنك نشر الدوالّ وحذفها وتعديلها باستخدام Firebase أوامر سطر الأوامر أو من خلال ضبط خيارات وقت التشغيل في رمز مصدر الدوالّ.
دوال النشر
لنشر الدوالّ، نفِّذ الأمر التالي لواجهة سطر أوامر Firebase:
firebase deploy --only functions
بشكلٍ تلقائي، تنشر واجهة برمجة التطبيقات Firebase CLI جميع الدوالّ داخل
مصدرك في الوقت نفسه. إذا كان مشروعك يحتوي على أكثر من 5 دوال،
ننصحك باستخدام العلامة --only
مع أسماء دوال معيّنة
لنشر الدوال التي
حرّرتها فقط. يؤدي نشر وظائف محددة
بهذه الطريقة إلى تسريع عملية النشر ويساعدك في تجنُّب الاستفادة من
حصص النشر. على سبيل المثال:
firebase deploy --only functions:addMessage,functions:makeUppercase
عند نشر أعداد كبيرة من الدوالّ، قد تتجاوز الحصة العادية وتتلقّى رسائل خطأ HTTP 429 أو 500. لحلّ هذه المشكلة، يمكنك نشر الدوالّ في مجموعات من 10 دوالّ أو أقل.
اطّلِع على Firebase مرجع واجهة سطر الأوامر للاطّلاع على القائمة الكاملة للسماحي باستخدامها.
يبحث Firebase CLI تلقائيًا في مجلد functions/
عن
رمز المصدر. يمكنك تنظيم الدوالّ
في قواعد بيانات أو مجموعات متعدّدة من الملفات إذا كنت تفضّل ذلك.
حذف الدوالّ
يمكنك حذف الدوال المنشورة سابقًا بالطرق التالية:
- بشكل صريح في واجهة سطر الأوامر Firebase باستخدام
functions:delete
- بشكل صريح في وحدة تحكّم Google Cloud.
- بشكل ضمني عن طريق إزالة الدالة من المصدر قبل نشرها
تطلب منك جميع عمليات الحذف confirm قبل إزالة الدالة من مرحلة الإنتاج.
يتيح لك حذف الدالة الصريح في Firebase CLI استخدام عدة مفاهيم بالإضافة إلى مجموعات الدوال ، كما يتيح لك تحديد دالة يتم تشغيلها في منطقة معيّنة. يمكنك أيضًا إلغاء طلب التأكيد.
# 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
تغيير منطقة أو مناطق الدالة
إذا كنت تغيّر المناطق المحدَّدة لوظيفة تعالج حركة بيانات الإنتاج، يمكنك منع فقدان الأحداث من خلال تنفيذ الخطوات التالية بالترتيب:
- أعد تسمية الدالة، وغيّر منطقتها أو مناطقها كما هو مطلوب.
- يمكنك نشر الدالة التي تمت إعادة تسميتها، ما يؤدي إلى تشغيل الرمز البرمجي نفسه مؤقتًا في كلتا مجموعتَي المناطق.
- احذف الدالة السابقة.
على سبيل المثال، إذا كانت لديك دالة مشغّلة باستخدام 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
.
تغيير نوع عامل تشغيل الدالة
أثناء تطوير عملية نشر Cloud Functions for Firebase بمرور الوقت، قد تحتاج إلى تغيير نوع مشغِّل الدالة لأسباب مختلفة. على سبيل المثال، قد تحتاج إلى تغيير نوع من أحداث Firebase Realtime Database أو Cloud Firestore إلى نوع آخر.
لا يمكن تغيير نوع حدث الدالة من خلال تغيير
الرمز المصدر وتشغيل firebase deploy
فقط. لتجنُّب حدوث أخطاء،
يمكنك تغيير نوع عامل تشغيل الدالة باتّباع الإجراء التالي:
- عدِّل الرمز المصدر لتضمين دالة جديدة بنوع العامل المشغِّل المطلوب.
- يمكنك نشر الدالة، ما يؤدي إلى تشغيل كلّ من الدالة القديمة والجديدة مؤقتًا.
- احذف الدالة القديمة من عملية الإنتاج صراحةً باستخدام واجهة سطر الأوامر 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 for Firebase اختيار خيارات وقت التشغيل، مثل إصدار وقت التشغيل Node.js والوقت الفائت لكل دالة وتخصيص الذاكرة والحد الأدنى/الحد الأقصى لمثيلات الدوالّ.
من أفضل الممارسات ضبط هذه الخيارات (باستثناء إصدار Node.js) على
كائن الإعدادات داخل رمز الدالة. يُعدّ كائن
RuntimeOptions
هذا مصدر حقيقة خيارات وقت تشغيل الدالة، وسيلغي
الخيارات التي تم ضبطها من خلال أيّ طريقة أخرى (مثلاً من خلال وحدة تحكّم Google Cloud
أو gcloud CLI).
إذا كان سير عمل التطوير يتضمن ضبط خيارات وقت التشغيل يدويًا من خلال Google Cloud Console أو واجهة سطر الأوامر gcloud، وكنت لا تريد إلغاء هذه القيم في كل عملية نشر، يمكنك ضبط الخيار preserveExternalChanges
على true
.
عند ضبط هذا الخيار على true
، تدمج Firebase خيارات وقت التشغيل التي تم ضبطها في
الرمز البرمجي مع إعدادات الإصدار المنشور حاليًا من الدالة مع
الأولوية التالية:
- يتم ضبط الخيار في رمز الدوال: إلغاء التغييرات الخارجية.
- تم ضبط الخيار على
RESET_VALUE
في رمز الدوال: إلغاء التغييرات الخارجية باستخدام القيمة التلقائية. - لم يتم ضبط الخيار في رمز الدوال، ولكن تم ضبطه في الدالة المنشورة حاليًا: استخدِم الخيار المحدّد في الدالة المنشورة.
لا يُنصح
باستخدام الخيار 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:
يمكنك ضبط الإصدار في حقل engines
في ملف package.json
الذي تم إنشاؤه في دليل functions/
أثناء الإعداد.
على سبيل المثال، لاستخدام الإصدار 18 فقط،
عدِّل هذا السطر في "package.json
":
"engines": {"node": "20"}
إذا كنت تستخدم مدير حِزم Yarn أو كانت لديك متطلبات محدّدة أخرى لمحاولة
حقل engines
، يمكنك ضبط وقت التشغيل لحزمة SDK الخاصة بنظام التشغيل Firebase لنظام التشغيل Cloud Functions في
firebase.json
بدلاً من ذلك:
{
"functions": {
"runtime": "nodejs18" // or nodejs20
}
}
يستخدم CLI القيمة المحدّدة في firebase.json
بدلاً من أي قيمة أو
نطاق تحدّده بشكل منفصل في package.json
.
ترقية وقت تشغيل Node.js
لترقية وقت تشغيل Node.js، اتّبِع الخطوات التالية:
- تأكَّد من أنّ مشروعك يستخدم خطة أسعار Blaze.
- يُرجى التأكّد من استخدام الإصدار 11.18.0 من واجهة سطر الأوامر Firebase أو إصدار أحدث.
- غيِّر قيمة
engines
في ملفpackage.json
الذي تم إنشاؤه في directoryfunctions/
أثناء الإعداد. على سبيل المثال، في حال الترقية من الإصدار 18 إلى الإصدار 20، من المفترض أن يظهر الإدخال على النحو التالي:"engines": {"node": "20"}
- يمكنك اختياريًا اختبار التغييرات باستخدام الرمز Firebase Local Emulator Suite.
- أعِد نشر جميع الدوالّ.
ضبط إصدار Python
تسمح حزمة Firebase SDK لإصدارات Cloud Functions 12.0.0 والإصدارات الأحدث باختيار وقت تنفيذ Python
. ضبط إصدار بيئة التشغيل في "firebase.json
" على النحو الموضّح:
{
"functions": {
"runtime": "python310" // or python311
}
}
التحكّم في سلوك التكبير/التصغير
يُعدِّل Cloud Functions for Firebase تلقائيًا عدد النُسخ التي تعمل استنادًا إلى عدد الطلبات الواردة، وقد ينخفض عدد النُسخ التي تعمل إلى صفر في أوقات انخفاض عدد الزيارات. ومع ذلك، إذا كان تطبيقك يتطلّب وقت استجابة منخفضًا وكنت تريد الحد من عدد عمليات بدء التشغيل البارد، يمكنك تغيير هذا السلوك التلقائي من خلال تحديد الحد الأدنى لعدد حاويات المثيلات التي يجب إبقاؤها قيد التشغيل والاستعداد لعرض الطلبات.
وبالمثل، يمكنك ضبط حد أقصى لعدد المثيلات للحدّ من توسيع المثيلات استجابة للطلبات الواردة. استخدِم هذا الإعداد كطريقة للتحكّم في تكاليفك أو لتقييد عدد عمليات الربط بخدمة احتياطية، مثل قاعدة بيانات.
باستخدام هذه الإعدادات مع إعداد التزامن لكل مثيل (جديد في الجيل الثاني)، يمكنك التحكّم في سلوك التحجيم وضبطه للدوال. تحدِّد طبيعة تطبيقك ووظيفة إعداداته الأكثر فعالية من حيث التكلفة والتي تحقّق أفضل أداء.
بالنسبة إلى بعض التطبيقات التي تتلقّى عددًا قليلاً من الزيارات، يكون خيار وحدة المعالجة المركزية (CPU) الأقلّ بدون تعدد المهام هو الخيار الأمثل. وبالنسبة إلى البعض الآخر الذي يكون فيه التشغيل على البارد مشكلة حرجة، فإن تعيين مستوى مرتفع من التزامن والحد الأدنى من الحالات يعني أن مجموعة من الحالات تكون دائمًا دافئة للتعامل مع الارتفاعات الكبيرة في عدد الزيارات.
بالنسبة إلى التطبيقات الأصغر حجمًا التي تتلقّى عددًا قليلاً جدًا من الزيارات، يعني ضبط الحد الأقصى المنخفض للمثيلات مع كثافة الاستخدام المتزامنة العالية أنّ التطبيق يمكنه التعامل مع الزيارات المفاجئة بدون تكبد تكاليف زائدة. ومع ذلك، يُرجى الأخذ في الاعتبار أنّه عندما يتم ضبط الحدّ الأقصى لعدد المثيلات على قيمة منخفضة جدًا، قد يتم تجاهل الطلبات عند بلوغ الحدّ الأقصى.
السماح بالطلبات المتزامنة
في Cloud Functions for Firebase (الجيل الأول)، يمكن لكلّ مثيل معالجة طلب واحد في المرّة، لذلك
لم يتمّ ضبط سلوك التوسّع إلا من خلال إعدادات الحدّ الأدنى والحدّ الأقصى للمثيل.
بالإضافة إلى التحكّم في عدد الحالات، يمكنك في Cloud Functions for Firebase (الجيل الثاني) التحكّم في عدد الطلبات التي يمكن لكل مثيل عرضها في الوقت نفسه باستخدام الخيار concurrency
. القيمة التلقائية للعمليات المتزامنة هي 80، ولكن يمكنك
ضبطها على أي عدد صحيح بين 1 و1,000.
ويمكن للدوال ذات إعدادات التزامن الأعلى استيعاب الارتفاعات المفاجئة في عدد الزيارات بدون البدء على البارد لأنه من المحتمل أن يكون لكل مثيل هامش للتحسين. إذا تم إعداد المثيل لمعالجة ما يصل إلى 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 عمليات مثيل على الأقل للحفاظ على الاحتفاظ بالبيانات:
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:
إليك بعض الأمور التي يجب مراعاتها عند ضبط الحد الأدنى لقيمة المثيلات:
- إذا وسّع 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 مثيل حتى لا تتعذّر معالجة قاعدة بيانات لنظام قائم افتراضيًا:
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:
- في وحدة تحكّم Google Cloud، اختَر Cloud Functions for Firebase من القائمة اليمنى.
- اختَر دالة من خلال النقر على اسمها في قائمة الدوال.
- انقر على رمز تعديل في القائمة العلوية.
- اختَر مساحة تخصيص ذاكرة من القائمة المنسدلة بعنوان المساحة المخصّصة للذاكرة.
- انقر على المزيد لعرض الخيارات المتقدمة، وأدخل عدد الثواني في مربع نص المهلة.
- انقر على حفظ لتعديل الدالة.
إلغاء الإعدادات التلقائية لوحدة المعالجة المركزية (CPU)
يتم تخصيص ما يصل إلى 2 غيغابايت من الذاكرة، ويتم ضبط كل دالة في Cloud Functions for Firebase (الجيل الثاني) تلقائيًا على وحدة معالجة مركزية واحدة، ثم تزيد إلى وحدتَي معالجة مركزية لسعة 4 و8 غيغابايت. يُرجى العلم أنّه يختلف هذا السلوك بشكل كبير عن السلوك التلقائي للجيل الأول بطرق قد يؤدي إلى تكاليف أعلى قليلاً للدوالّ التي تستهلك ذاكرة منخفضة كما هو موضّح في الجدول التالي:
ذاكرة الوصول العشوائي المخصّصة | وحدة المعالجة المركزية التلقائية للإصدار 1 (كسور) | وحدة المعالجة المركزية التلقائية في الإصدار 2 | زيادة السعر لكل ملي ثانية |
---|---|---|---|
128 ميغابايت | 1/12 | 1 | 10.5x |
256 ميغابايت | 1/6 | 1 | 5.3x |
512 ميغابايت | 1/3 | 1 | أسرع بـ 2,7 مرة |
1 غيغابايت | 7/12 | 1 | 1.6x |
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) حسب كل وظيفة على النحو الموضح:
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