يمكنك نشر الدوال وحذفها وتعديلها باستخدام Firebase أوامر سطر الأوامر أو من خلال ضبط خيارات وقت التشغيل في رمز مصدر الدوال.
نشر الدوالّ
لنشر الدوالّ، نفِّذ الأمر التالي لواجهة سطر أوامر Firebase:
firebase deploy --only functions
بشكلٍ تلقائي، تنشر واجهة برمجة التطبيقات Firebase CLI جميع الدوالّ داخل
مصدرك في الوقت نفسه. إذا كان مشروعك يحتوي على أكثر من 5 دوال،
ننصحك باستخدام العلامة --only
مع أسماء دوال محدّدة
لنشر الدوال التي
حرّرتها فقط. يؤدي نشر وظائف معيّنة
بهذه الطريقة إلى تسريع عملية النشر ومساعدتك في تجنّب مواجهة quot;الحصص القصوى للنشر". على سبيل المثال:
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 CLI.
على سبيل المثال، إذا كانت لديك دالة يتم تنشيطها عند حذف كائن، ولكن بعد ذلك فعّلت ميزة حفظ الإصدارات السابقة من الكائنات وأردت الاشتراك في حدث الأرشفة بدلاً من ذلك، عليك أولاً إعادة تسمية الدالة وتعديلها لتكون من النوع الجديد للعامل المشغِّل.
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 CLI ولا تريد أن يتم
تجاوز هذه القيم في كل عملية نشر، اضبط الخيار preserveExternalChanges
على true
.
عند ضبط هذا الخيار على true
، تدمج Firebase خيارات وقت التشغيل التي تم ضبطها في
الرمز البرمجي مع إعدادات الإصدار المنشور حاليًا من الدالة باستخدام
الأولوية التالية:
- يتم ضبط الخيار في رمز الدوال: إلغاء التغييرات الخارجية.
- تم ضبط الخيار على
RESET_VALUE
في رمز الدوال: إلغاء التغييرات الخارجية باستخدام القيمة التلقائية. - لم يتم ضبط الخيار في رمز الدوال، ولكن تم ضبطه في الدالة المنشورة حاليًا: استخدِم الخيار المحدّد في الدالة المنشورة.
لا يُنصح
باستخدام الخيار 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
تم إيقاف إصدارَي Node.js 14 و16 نهائيًا وسيتم إيقافهما نهائيًا في أوائل عام 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 CLI.
- غيِّر قيمة
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 من القائمة اليمنى.
- اختَر دالة من خلال النقر على اسمها في قائمة الدوال.
- انقر على رمز تعديل في القائمة العلوية.
- اختَر مساحة تخصيص ذاكرة من القائمة المنسدلة بعنوان المساحة المخصّصة للذاكرة.
- انقر على المزيد لعرض الخيارات المتقدّمة، وأدخِل عددًا من الثواني في مربّع نص المهلة.
- انقر على حفظ لتعديل الدالة.
إلغاء الإعدادات التلقائية لوحدة المعالجة المركزية
يتم تخصيص ما يصل إلى 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.7x |
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")
بالنسبة إلى الوظائف التي تتطلّب استخدامًا مكثّفًا لوحدة المعالجة المركزية، توفّر الجيل الثاني المرونة في ضبط معالج إضافي. يمكنك زيادة سرعة وحدة المعالجة المركزية لكل دالة على حدة كما هو موضّح:
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