คุณสามารถทำให้ใช้งานได้ ลบ และแก้ไขฟังก์ชันโดยใช้Firebaseคำสั่ง CLI หรือโดยการตั้งค่าตัวเลือกรันไทม์ในซอร์สโค้ดของฟังก์ชัน
ทำให้ฟังก์ชันใช้งานได้
หากต้องการทำให้ฟังก์ชันใช้งานได้ ให้เรียกใช้คำสั่ง Firebase CLI นี้
firebase deploy --only functions
โดยค่าเริ่มต้น Firebase CLI จะติดตั้งใช้งานฟังก์ชันทั้งหมดในแหล่งที่มาของคุณพร้อมกัน หากโปรเจ็กต์มีฟังก์ชันมากกว่า 5 รายการ เราขอแนะนำให้ใช้ Flag --only
ที่มีชื่อฟังก์ชันที่เฉพาะเจาะจงเพื่อทำให้ใช้งานได้เฉพาะฟังก์ชันที่คุณแก้ไข การทําให้ฟังก์ชันที่เฉพาะเจาะจงใช้งานได้วิธีนี้จะช่วยเร่งกระบวนการทําให้ใช้งานได้และช่วยให้คุณหลีกเลี่ยงการถึงโควต้าการทําให้ใช้งานได้ เช่น
firebase deploy --only functions:addMessage,functions:makeUppercase
เมื่อติดตั้งใช้งานฟังก์ชันจํานวนมาก คุณอาจใช้โควต้ามาตรฐานเกินและได้รับข้อความแสดงข้อผิดพลาด HTTP 429 หรือ 500 วิธีแก้ปัญหานี้คือให้ติดตั้งใช้งานฟังก์ชันเป็นกลุ่มๆ ไม่เกิน 10 รายการ
ดูรายการคำสั่งทั้งหมดที่พร้อมใช้งานได้ในFirebaseข้อมูลอ้างอิง CLI
โดยค่าเริ่มต้น Firebase CLI จะค้นหาซอร์สโค้ดในโฟลเดอร์ functions/
หากต้องการ คุณสามารถจัดระเบียบฟังก์ชันในโค้ดเบสหรือไฟล์หลายชุดได้
ลบฟังก์ชัน
คุณลบฟังก์ชันที่ติดตั้งใช้งานไปก่อนหน้านี้ได้ดังนี้
- อย่างชัดเจนใน Firebase CLI ด้วย
functions:delete
- อย่างชัดเจนในคอนโซล Google Cloud
- โดยปริยาย โดยนำฟังก์ชันออกจากซอร์สก่อนทำให้ใช้งานได้
การดำเนินการลบทั้งหมดจะแจ้งให้คุณยืนยันก่อนนำฟังก์ชันออกจากเวอร์ชันที่ใช้งานจริง
การลบฟังก์ชันอย่างชัดแจ้งใน 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
จะแยกวิเคราะห์แหล่งที่มาและนำฟังก์ชันที่นําออกจากไฟล์ออกจากเวอร์ชันที่ใช้งานจริง
แก้ไขชื่อ ภูมิภาค หรือทริกเกอร์ของฟังก์ชัน
หากคุณต้องการเปลี่ยนชื่อหรือเปลี่ยนภูมิภาคหรือทริกเกอร์สําหรับฟังก์ชันที่จัดการการเข้าชมเวอร์ชันที่ใช้งานจริง ให้ทําตามขั้นตอนในส่วนนี้เพื่อหลีกเลี่ยงการสูญเสียเหตุการณ์ระหว่างการแก้ไข ก่อนทำตามขั้นตอนเหล่านี้ ให้ตรวจสอบก่อนว่าฟังก์ชันทำงานแบบไม่ซ้ำกัน เนื่องจากทั้งฟังก์ชันเวอร์ชันใหม่และเวอร์ชันเก่าจะทำงานพร้อมกันในระหว่างการเปลี่ยนแปลง
เปลี่ยนชื่อฟังก์ชัน
หากต้องการเปลี่ยนชื่อฟังก์ชัน ให้สร้างฟังก์ชันเวอร์ชันใหม่ที่มีชื่อใหม่ในแหล่งที่มา แล้วเรียกใช้คำสั่งทำให้ใช้งานได้ 2 รายการแยกกัน คำสั่งแรกจะทําให้ฟังก์ชันที่มีชื่อใหม่ใช้งานได้ และคำสั่งที่ 2 จะนําเวอร์ชันที่ทําให้ใช้งานได้ก่อนหน้านี้ออก เช่น หากมี Webhook ที่ทริกเกอร์โดย 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
เปลี่ยนภูมิภาคของฟังก์ชัน
หากจะเปลี่ยนภูมิภาคที่ระบุสำหรับฟังก์ชันที่จัดการการเข้าชมเวอร์ชันที่ใช้งานจริง คุณสามารถป้องกันไม่ให้เหตุการณ์สูญหายได้โดยทําตามขั้นตอนต่อไปนี้
- เปลี่ยนชื่อฟังก์ชันและเปลี่ยนภูมิภาคของฟังก์ชันตามที่คุณต้องการ
- ติดตั้งใช้งานฟังก์ชันที่เปลี่ยนชื่อ ซึ่งจะทําให้เรียกใช้โค้ดเดียวกันในทั้ง 2 ชุดของภูมิภาคชั่วคราว
- ลบฟังก์ชันก่อนหน้า
ตัวอย่างเช่น หากคุณมีฟังก์ชันที่ทริกเกอร์ด้วย 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
ตอนนี้มีฟังก์ชันที่เหมือนกัน 2 รายการที่ทำงานอยู่ โดย 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 หรือ gcloud CLI และคุณไม่ต้องการให้ระบบลบล้างค่าเหล่านี้ในการทำให้ใช้งานได้แต่ละครั้ง ให้ตั้งค่าตัวเลือก preserveExternalChanges
เป็น true
เมื่อตั้งค่าตัวเลือกนี้เป็น true
Firebase จะผสานรวมตัวเลือกรันไทม์ที่ตั้งค่าไว้ในโค้ดกับการตั้งค่าของฟังก์ชันเวอร์ชันที่ทำให้ใช้งานได้อยู่ในปัจจุบันซึ่งมีลำดับความสำคัญดังต่อไปนี้
- ตัวเลือกตั้งค่าไว้ในโค้ดฟังก์ชัน: ลบล้างการเปลี่ยนแปลงภายนอก
- ตัวเลือกเป็น
RESET_VALUE
ในโค้ดฟังก์ชัน: ลบล้างการเปลี่ยนแปลงภายนอกด้วยค่าเริ่มต้น - ไม่ได้ตั้งค่าตัวเลือกในโค้ดฟังก์ชัน แต่ตั้งค่าไว้ในฟังก์ชันที่ใช้งานอยู่ในปัจจุบัน: ใช้ตัวเลือกที่ระบุไว้ในฟังก์ชันที่ใช้งานอยู่
ไม่แนะนำให้ใช้ตัวเลือก preserveExternalChanges: true
กับสถานการณ์ส่วนใหญ่เนื่องจากโค้ดจะไม่ใช่แหล่งที่มาที่ถูกต้องทั้งหมดของตัวเลือกรันไทม์สำหรับฟังก์ชันอีกต่อไป หากใช้ โปรดตรวจสอบคอนโซล Google Cloud หรือใช้ gcloud CLI เพื่อดูการกําหนดค่าแบบเต็มของฟังก์ชัน
ตั้งค่าเวอร์ชัน Node.js
Firebase SDK สําหรับ 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
คุณสามารถตั้งค่ารันไทม์สำหรับ Firebase SDK สำหรับ Cloud Functions ใน firebase.json
แทนได้ ดังนี้
{
"functions": {
"runtime": "nodejs18" // or nodejs20
}
}
CLI จะใช้ค่าที่ตั้งไว้ใน firebase.json
แทนค่าหรือช่วงที่คุณตั้งไว้แยกต่างหากใน package.json
อัปเกรดรันไทม์ของ Node.js
วิธีอัปเกรดรันไทม์ Node.js
- ตรวจสอบว่าโปรเจ็กต์อยู่ในแพ็กเกจราคา Blaze
- ตรวจสอบว่าคุณใช้ Firebase CLI v11.18.0 ขึ้นไป
- เปลี่ยนค่า
engines
ในไฟล์package.json
ที่สร้างขึ้นในไดเรกทอรีfunctions/
ในระหว่างการเริ่มต้น ตัวอย่างเช่น หากคุณจะอัปเกรดจากเวอร์ชัน 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 จะปรับขนาดจำนวนอินสแตนซ์ที่ทำงานอยู่ตามจำนวนคำขอขาเข้า และอาจปรับขนาดให้เหลือ 0 อินสแตนซ์เมื่อการรับส่งข้อมูลลดลง อย่างไรก็ตาม หากแอปของคุณต้องการเวลาในการตอบสนองที่ลดลงและคุณต้องการจำกัดจำนวนการเริ่มต้นแบบเย็น คุณสามารถเปลี่ยนลักษณะการทำงานเริ่มต้นนี้ได้โดยการระบุจำนวนอินสแตนซ์คอนเทนเนอร์ขั้นต่ำที่จะเก็บไว้และพร้อมให้บริการคำขอ
ในทํานองเดียวกัน คุณสามารถกําหนดจํานวนสูงสุดเพื่อจํากัดการปรับขนาดอินสแตนซ์เพื่อตอบสนองต่อคําขอขาเข้า ใช้การตั้งค่านี้เป็นวิธีควบคุมต้นทุนหรือจํากัดจํานวนการเชื่อมต่อกับบริการแบ็กเอนด์ เช่น ฐานข้อมูล
การใช้การตั้งค่าเหล่านี้ร่วมกับการตั้งค่าการเกิดขึ้นพร้อมกันตามอินสแตนซ์ (ใหม่ในรุ่นที่ 2) จะช่วยให้คุณควบคุมและปรับแต่งลักษณะการปรับขนาดสำหรับฟังก์ชันได้ ลักษณะของแอปพลิเคชันและฟังก์ชันจะกำหนดว่าการตั้งค่าใด คุ้มค่าที่สุดและส่งผลให้เกิดประสิทธิภาพที่ดีที่สุด
สําหรับแอปบางแอปที่มีการเข้าชมต่ำ ตัวเลือก CPU ที่ต่ำลงโดยไม่มีการทำงานพร้อมกันหลายรายการจะเหมาะที่สุด สําหรับกรณีอื่นๆ ที่การเริ่มต้นแบบ Cold Start เป็นปัญหาร้ายแรง การตั้งค่าการทํางานพร้อมกันสูงและอินสแตนซ์ขั้นต่ำหมายความว่าระบบจะเก็บชุดอินสแตนซ์ไว้เสมอเพื่อจัดการกับการเข้าชมที่เพิ่มขึ้นอย่างรวดเร็ว
สำหรับแอปขนาดเล็กที่ได้รับการเข้าชมน้อยมาก การตั้งค่าอินสแตนซ์สูงสุดระดับต่ำให้เกิดขึ้นพร้อมกันสูงจะช่วยให้แอปรองรับการเข้าชมจำนวนมากโดยไม่ต้องเสียค่าใช้จ่ายมากเกินไป อย่างไรก็ตาม โปรดทราบว่าการตั้งค่าอินสแตนซ์สูงสุดต่ำเกินไปอาจทำให้ระบบทิ้งคําขอเมื่อถึงขีดจํากัด
อนุญาตคำขอหลายรายการพร้อมกัน
ใน Cloud Functions for Firebase (รุ่นที่ 1) แต่ละอินสแตนซ์จะจัดการคำขอได้ครั้งละ 1 รายการเท่านั้น ระบบจึงตั้งค่าลักษณะการปรับขนาดด้วยการตั้งค่าอินสแตนซ์ขั้นต่ำและสูงสุดเท่านั้น
นอกจากการควบคุมจำนวนอินสแตนซ์แล้ว ใน Cloud Functions for Firebase (รุ่นที่ 2) คุณยังควบคุมจำนวนคำขอที่อินสแตนซ์แต่ละรายการจะให้บริการพร้อมกันได้ด้วยตัวเลือก concurrency
ค่าเริ่มต้นสำหรับการเกิดขึ้นพร้อมกันคือ 80 แต่คุณสามารถตั้งค่าเป็นจำนวนเต็มใดก็ได้ระหว่าง 1 ถึง 1000
ฟังก์ชันที่มีการตั้งค่าการเรียกใช้พร้อมกันสูงกว่าจะรองรับการเข้าชมที่เพิ่มขึ้นได้โดยไม่ต้องเริ่มทำงานใหม่ เนื่องจากอินสแตนซ์แต่ละรายการมี Headroom อยู่บ้าง หากอินสแตนซ์ได้รับการกำหนดค่าให้จัดการคำขอพร้อมกันได้สูงสุด 50 รายการ แต่ปัจจุบันจัดการได้เพียง 25 รายการ อินสแตนซ์จะจัดการคำขอที่เพิ่มขึ้นอีก 25 รายการได้โดยไม่ต้องเริ่มอินสแตนซ์ใหม่ ในทางตรงกันข้าม เมื่อตั้งค่าการเรียกใช้พร้อมกันเป็น 1 เท่านั้น จำนวนคำขอที่เพิ่มขึ้นอาจทําให้เกิด Cold Start 25 ครั้ง
สถานการณ์ที่เข้าใจง่ายนี้แสดงให้เห็นถึงประสิทธิภาพที่อาจเพิ่มขึ้นจากการทำงานพร้อมกัน ในทางปฏิบัติ ลักษณะการปรับขนาดเพื่อเพิ่มประสิทธิภาพและลดการเริ่มต้นแบบ Cold Start พร้อมกันนั้นมีความซับซ้อนมากกว่า การทำงานพร้อมกันใน Cloud Functions for Firebase รุ่นที่ 2 ทำงานด้วย Cloud Run และเป็นไปตามกฎของ Cloud Run เกี่ยวกับการปรับขนาดอินสแตนซ์คอนเทนเนอร์อัตโนมัติ
เมื่อทดสอบการตั้งค่าการเรียกใช้พร้อมกันที่สูงขึ้นใน Cloud Functions for Firebase (รุ่นที่ 2) โปรดคำนึงถึงสิ่งต่อไปนี้
- การตั้งค่าการเรียกใช้หลายรายการพร้อมกันที่สูงขึ้นอาจต้องใช้ CPU และ RAM มากขึ้นเพื่อให้ได้ประสิทธิภาพที่ดีที่สุดจนกว่าจะถึงขีดจำกัดที่ใช้งานได้จริง ตัวอย่างเช่น ฟังก์ชันที่ประมวลผลรูปภาพหรือวิดีโออย่างหนักอาจไม่มีทรัพยากรเพียงพอที่จะจัดการคำขอพร้อมกัน 1,000 รายการ แม้ว่าจะตั้งค่า CPU และ RAM ไว้สูงสุดแล้วก็ตาม
- เนื่องจาก Cloud Functions for Firebase (รุ่นที่ 2) ทำงานด้วย 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 ปรับขนาดแอปสูงกว่าการตั้งค่าของคุณ คุณจะเห็นการเริ่มต้นแบบ Cold Start สําหรับแต่ละอินสแตนซ์ที่สูงกว่าเกณฑ์นั้น
- การเริ่มต้นแบบ Cold Start จะส่งผลร้ายแรงที่สุดต่อแอปที่มีการเข้าชมสูงชัน หากแอปมีการเข้าชมที่พุ่งสูงขึ้นและคุณกำหนดค่าไว้สูงพอที่ Cold Start จะลดลงสำหรับการเข้าชมแต่ละครั้งที่เพิ่มขึ้น คุณจะเห็นเวลาในการตอบสนองที่ลดลงอย่างมาก สําหรับแอปที่มีการเข้าชมอย่างต่อเนื่อง Cold Start ไม่น่าส่งผลกระทบต่อประสิทธิภาพอย่างรุนแรง
การตั้งค่าอินสแตนซ์ขั้นต่ำอาจเหมาะกับสภาพแวดล้อมที่ใช้งานจริง แต่โดยทั่วไปควรหลีกเลี่ยงในสภาพแวดล้อมการทดสอบ หากต้องการปรับขนาดเป็น 0 ในโปรเจ็กต์ทดสอบแต่ยังคงลดการเริ่มต้นระบบใหม่ในโปรเจ็กต์เวอร์ชันที่ใช้งานจริง คุณสามารถกําหนดค่าอินสแตนซ์ขั้นต่ำในการกําหนดค่าที่มีพารามิเตอร์ ดังนี้
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 นี้ใช้หน่วยความจํา 1GiB และหมดเวลาหลังจาก 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 GB แต่ละฟังก์ชันใน Cloud Functions for Firebase (รุ่นที่ 2) จะเริ่มต้นด้วย CPU 1 ตัว แล้วเพิ่มเป็น 2 ตัวสําหรับ 4 และ 8 GB โปรดทราบว่าวิธีนี้แตกต่างจากลักษณะการทำงานเริ่มต้นของรุ่นที่ 1 อย่างมากในลักษณะที่อาจทำให้มีค่าใช้จ่ายสำหรับฟังก์ชันที่มีหน่วยความจำต่ำสูงขึ้นเล็กน้อย ดังที่แสดงในตารางต่อไปนี้
RAM ที่จัดสรร | CPU เริ่มต้นเวอร์ชัน 1 (เศษส่วน) | CPU เริ่มต้นของเวอร์ชัน 2 | การขึ้นราคาต่อมิลลิวินาที |
---|---|---|---|
128 MB | 1/12 | 1 | 10.5 เท่า |
256MB | 1/6 | 1 | 5.3 เท่า |
512MB | 1/3 | 1 | 2.7 เท่า |
1GB | 7/12 | 1 | 1.6 เท่า |
2GB | 1 | 1 | 1x |
4 GB | 2 | 2 | 1x |
8 GB | 2 | 2 | 1x |
16 GB | ไม่มี | 4 | ไม่มี |
หากต้องการใช้การทำงานรุ่นที่ 1 สำหรับฟังก์ชันรุ่นที่ 2 ให้ตั้งค่าเริ่มต้นของรุ่นที่ 1 เป็นตัวเลือกส่วนกลางดังนี้
Node.js
// Turn off Firebase defaults
setGlobalOptions({ cpu: 'gcf_gen1' });
Python
# Use 1st gen behavior
set_global_options(cpu="gcf_gen1")
สำหรับฟังก์ชันที่ต้องใช้ CPU อย่างหนัก เวอร์ชันที่ 2 ให้ความยืดหยุ่นในการกำหนดค่า 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