คุณสามารถติดตั้งใช้งาน ลบ และแก้ไขฟังก์ชันได้โดยใช้Firebaseคำสั่ง CLI หรือโดยการตั้งค่าตัวเลือกเวลาเรียกใช้ในซอร์สโค้ดของฟังก์ชัน
ทำให้ฟังก์ชันใช้งานได้
หากต้องการทําให้ฟังก์ชันใช้งานได้ ให้เรียกใช้คําสั่ง Firebase CLI นี้
firebase deploy --only functions
โดยค่าเริ่มต้น Firebase CLI จะทําการติดตั้งฟังก์ชันทั้งหมดภายใน
แหล่งที่มาของคุณพร้อมกัน หากโปรเจ็กต์มีฟังก์ชันมากกว่า 5 รายการ
เราขอแนะนำให้ใช้แฟล็ก --only
พร้อมชื่อฟังก์ชันที่เฉพาะเจาะจง
เพื่อทำให้เฉพาะฟังก์ชันที่คุณแก้ไข
ได้รับการติดตั้งใช้งาน การติดตั้งฟังก์ชันที่เฉพาะเจาะจงด้วยวิธีนี้จะช่วยเร่งกระบวนการติดตั้งใช้งานและช่วยให้คุณไม่ต้องกังวลเกี่ยวกับโควต้าการติดตั้งใช้งาน
เช่น
firebase deploy --only functions:addMessage,functions:makeUppercase
เมื่อติดตั้งใช้งานฟังก์ชันจำนวนมาก คุณอาจใช้โควต้ามาตรฐานเกินและได้รับข้อความแสดงข้อผิดพลาด HTTP 429 หรือ 500 หากต้องการแก้ไข ปัญหานี้ ให้ติดตั้งใช้งานฟังก์ชันเป็นกลุ่มๆ ละไม่เกิน 10 รายการ
ดูรายการคำสั่งทั้งหมดที่พร้อมใช้งานได้ที่Firebaseข้อมูลอ้างอิง CLI
โดยค่าเริ่มต้น Firebase CLI จะค้นหารหัสต้นฉบับในโฟลเดอร์ functions/
หากต้องการ คุณสามารถจัดระเบียบฟังก์ชัน
ในโค้ดเบสหรือชุดไฟล์หลายชุดได้
ล้างข้อมูลอาร์ติแฟกต์การติดตั้งใช้งาน
ในขั้นตอนการทําให้ฟังก์ชันใช้งานได้ ระบบจะสร้างและจัดเก็บอิมเมจคอนเทนเนอร์ใน Artifact Registry คุณไม่จำเป็นต้องใช้รูปภาพเหล่านี้เพื่อให้ฟังก์ชันที่ติดตั้งใช้งานทำงาน Cloud Functions จะดึงและเก็บสำเนาของรูปภาพไว้ในการติดตั้งใช้งานครั้งแรก แต่ไม่จำเป็นต้องมีอาร์ติแฟกต์ที่จัดเก็บไว้เพื่อให้ฟังก์ชันทำงาน ในรันไทม์
แม้ว่าอิมเมจคอนเทนเนอร์เหล่านี้มักจะมีขนาดเล็ก แต่ก็อาจสะสมไปเรื่อยๆ เมื่อเวลาผ่านไปและทำให้ค่าใช้จ่ายในการจัดเก็บเพิ่มขึ้น คุณอาจต้องการเก็บไว้สักระยะหนึ่งหากวางแผนที่จะตรวจสอบอาร์ติแฟกต์ที่สร้างขึ้นหรือเรียกใช้การสแกนช่องโหว่ของคอนเทนเนอร์
Firebase CLI 14.0.0 ขึ้นไปช่วยให้คุณกำหนดค่าArtifact Registryนโยบายการล้างข้อมูล สำหรับที่เก็บที่จัดเก็บอาร์ติแฟกต์การติดตั้งใช้งานหลังจากติดตั้งใช้งานฟังก์ชันแต่ละรายการ เพื่อช่วยจัดการค่าใช้จ่ายในการจัดเก็บข้อมูล
คุณตั้งค่าหรือแก้ไขนโยบายการล้างข้อมูลด้วยตนเองได้โดยใช้คำสั่ง
functions:artifacts:setpolicy
firebase functions:artifacts:setpolicy
โดยค่าเริ่มต้น คำสั่งนี้จะกำหนดค่า Artifact Registry ให้ลบอิมเมจคอนเทนเนอร์ที่มีอายุมากกว่า 1 วันโดยอัตโนมัติ ซึ่งจะช่วยรักษาสมดุลที่เหมาะสมระหว่าง การลดต้นทุนพื้นที่เก็บข้อมูลและการอนุญาตให้ตรวจสอบบิลด์ล่าสุดได้
คุณปรับแต่งระยะเวลาการเก็บรักษาได้โดยใช้ตัวเลือก --days
ดังนี้
firebase functions:artifacts:setpolicy --days 7 # Delete images older than 7 days
หากติดตั้งใช้งานฟังก์ชันในหลายภูมิภาค คุณสามารถตั้งค่านโยบายการล้างข้อมูลสำหรับ
สถานที่ตั้งที่เฉพาะเจาะจงได้โดยใช้ตัวเลือก --location
ดังนี้
$ firebase functions:artifacts:setpolicy --location europe-west1
เลือกไม่ใช้การล้างข้อมูลอาร์ติแฟกต์
หากต้องการจัดการการล้างรูปภาพด้วยตนเอง หรือไม่ต้องการให้ระบบลบรูปภาพใดๆ คุณสามารถเลือกไม่ใช้นโยบายการล้างข้อมูลทั้งหมดได้โดยทำดังนี้
$ firebase functions:artifacts:setpolicy --none
คำสั่งนี้จะนำนโยบายการล้างข้อมูลที่มีอยู่ซึ่ง Firebase CLI ได้ตั้งค่าไว้ ออก และป้องกันไม่ให้ Firebase ตั้งค่านโยบายการล้างข้อมูลหลังจากทำให้ฟังก์ชัน ใช้งานได้
ลบฟังก์ชัน
คุณลบฟังก์ชันที่ติดตั้งใช้งานก่อนหน้านี้ได้ด้วยวิธีต่อไปนี้
- อย่างชัดเจนใน 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 คำสั่งแยกกัน คำสั่งแรกจะทำให้ฟังก์ชันที่ตั้งชื่อใหม่ ใช้งานได้ และคำสั่งที่สองจะนำเวอร์ชันที่ทำให้ใช้งานได้ก่อนหน้านี้ ออก เช่น หากคุณมีเว็บบุ๊กที่ทริกเกอร์ด้วย 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
เปลี่ยนภูมิภาคของฟังก์ชัน
หากคุณกำลังเปลี่ยนภูมิภาคที่ระบุสำหรับฟังก์ชันที่จัดการการเข้าชมในเวอร์ชันที่ใช้งานจริง คุณสามารถป้องกันการสูญเสียเหตุการณ์ได้โดยทำตามขั้นตอนต่อไปนี้ตามลำดับ
- เปลี่ยนชื่อฟังก์ชัน และเปลี่ยนภูมิภาคตามต้องการ
- ทําการติดตั้งใช้งานฟังก์ชันที่เปลี่ยนชื่อแล้ว ซึ่งจะทําให้โค้ดเดียวกันทํางานชั่วคราวในทั้ง 2 ชุดภูมิภาค
- ลบฟังก์ชันก่อนหน้า
ตัวอย่างเช่น หากคุณมี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) => {},
);
โค้ดที่อัปเดตควรระบุตัวกรองเหตุการณ์ที่ถูกต้อง (ในกรณีนี้คือ
document
) พร้อมกับภูมิภาค ดูข้อมูลเพิ่มเติมได้ที่Cloud Functionsสถานที่ตั้ง
# 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
ตัวอย่างเช่น หากคุณมีฟังก์ชันที่ทริกเกอร์เมื่อมีการลบออบเจ็กต์ แต่ต่อมาคุณได้เปิดใช้การควบคุมเวอร์ชันออบเจ็กต์และต้องการสมัครรับข้อมูลเหตุการณ์เก็บถาวรแทน ให้เปลี่ยนชื่อฟังก์ชันก่อน แล้วแก้ไขให้มีประเภททริกเกอร์ใหม่
// 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 Console
หรือ gcloud CLI)
หากเวิร์กโฟลว์การพัฒนาของคุณเกี่ยวข้องกับการตั้งค่าตัวเลือกเวลาเรียกใช้ด้วยตนเองผ่าน
Google Cloud Console หรือ gcloud CLI และคุณไม่ต้องการให้ค่าเหล่านี้ถูก
ลบล้างในการติดตั้งใช้งานแต่ละครั้ง ให้ตั้งค่าตัวเลือก preserveExternalChanges
เป็น true
เมื่อตั้งค่าตัวเลือกนี้เป็น true
Firebase จะผสานตัวเลือกเวลาเรียกใช้ที่ตั้งค่าไว้ในโค้ดกับ
การตั้งค่าของฟังก์ชันเวอร์ชันที่กําลังใช้งานอยู่โดยมีลําดับความสําคัญดังนี้
- ตั้งค่าตัวเลือกในโค้ดฟังก์ชัน: ลบล้างการเปลี่ยนแปลงภายนอก
- ตั้งค่าเป็น
RESET_VALUE
ในโค้ดฟังก์ชัน: ลบล้างการเปลี่ยนแปลงภายนอกด้วยค่าเริ่มต้น - ไม่ได้ตั้งค่าตัวเลือกในโค้ดฟังก์ชัน แต่ตั้งค่าในฟังก์ชันที่ทําให้ใช้งานได้ในปัจจุบัน: ใช้ตัวเลือกที่ระบุในฟังก์ชันที่ทําให้ใช้งานได้
preserveExternalChanges: true
ไม่แนะนำให้ใช้ตัวเลือก preserveExternalChanges: true
ในกรณีส่วนใหญ่ เนื่องจากโค้ดของคุณจะไม่ใช่แหล่งข้อมูลที่เชื่อถือได้ทั้งหมดสำหรับตัวเลือกเวลาเรียกใช้ของฟังก์ชันอีกต่อไป
หากคุณใช้ ให้ตรวจสอบ Google Cloud Console หรือใช้ 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 เวอร์ชันเหล่านี้อย่างต่อเนื่อง
วิธีตั้งค่าเวอร์ชัน Node.js
คุณตั้งค่าเวอร์ชันได้ในฟิลด์ engines
ในpackage.json
ไฟล์ที่สร้างในไดเรกทอรี functions/
ระหว่างการเริ่มต้น
เช่น หากต้องการใช้เฉพาะ
เวอร์ชัน 20 ให้แก้ไขบรรทัดนี้ใน package.json
"engines": {"node": "20"}
หากคุณใช้เครื่องมือจัดการแพ็กเกจ Yarn หรือมีข้อกำหนดอื่นๆ สำหรับฟิลด์ engines
คุณสามารถตั้งค่ารันไทม์สำหรับ SDK ของ Firebase สำหรับ Cloud Functions ใน firebase.json
แทนได้
{
"functions": {
"runtime": "nodejs20" // or nodejs22
}
}
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 เป็นปัญหาสำคัญ การตั้งค่า Concurrency สูงและอินสแตนซ์ขั้นต่ำหมายความว่าระบบจะรักษาชุดอินสแตนซ์ให้พร้อมใช้งานอยู่เสมอเพื่อรองรับการเพิ่มขึ้นของการเข้าชมจำนวนมาก
สำหรับแอปขนาดเล็กที่ได้รับการเข้าชมน้อยมาก การตั้งค่าอินสแตนซ์สูงสุดต่ำที่มีการทำงานพร้อมกันสูงหมายความว่าแอปจะจัดการการเข้าชมที่เพิ่มขึ้นได้โดยไม่ต้องเสียค่าใช้จ่ายมากเกินไป อย่างไรก็ตาม โปรดทราบว่าหากตั้งค่า maximum instances ต่ำเกินไป ระบบอาจทิ้งคำขอเมื่อถึงขีดจำกัด
อนุญาตคำขอพร้อมกัน
ใน Cloud Functions for Firebase (รุ่นที่ 1) แต่ละอินสแตนซ์จะจัดการคำขอได้ครั้งละ 1 รายการเท่านั้น ดังนั้น
ลักษณะการทำงานของการปรับขนาดจึงตั้งค่าได้เฉพาะการตั้งค่าอินสแตนซ์ขั้นต่ำและสูงสุด
นอกเหนือจากการควบคุมจำนวนอินสแตนซ์แล้ว ใน Cloud Functions for Firebase (รุ่นที่ 2) คุณ
สามารถควบคุมจำนวนคำขอที่แต่ละอินสแตนซ์แสดงพร้อมกันได้ด้วย
ตัวเลือก concurrency
ค่าเริ่มต้นสำหรับความพร้อมกันคือ 80 แต่คุณ
ตั้งค่าเป็นจำนวนเต็มใดก็ได้ระหว่าง 1 ถึง 1, 000
ฟังก์ชันที่มีการตั้งค่าการทำงานพร้อมกันสูงกว่าจะรองรับปริมาณการเข้าชมที่เพิ่มขึ้นได้โดยไม่ต้อง เริ่มแบบเย็น เนื่องจากแต่ละอินสแตนซ์น่าจะมีพื้นที่ว่างอยู่บ้าง หากอินสแตนซ์ได้รับการกำหนดค่าให้จัดการคำขอพร้อมกันได้สูงสุด 50 รายการ แต่ปัจจุบันจัดการได้เพียง 25 รายการ อินสแตนซ์จะจัดการคำขอที่เพิ่มขึ้นอีก 25 รายการได้โดยไม่ต้องให้ อินสแตนซ์ใหม่เริ่มทำงาน ในทางตรงกันข้าม หากตั้งค่าการทำงานพร้อมกันเป็น 1 การเพิ่มขึ้นของคำขอ ดังกล่าวอาจทำให้เกิดการเริ่มระบบใหม่ 25 ครั้ง
สถานการณ์จำลองที่เรียบง่ายนี้แสดงให้เห็นถึงประสิทธิภาพที่อาจเพิ่มขึ้นได้จาก การทำงานพร้อมกัน ในความเป็นจริง การปรับขนาดลักษณะการทำงานเพื่อเพิ่มประสิทธิภาพและลด การเริ่มระบบแบบเย็นด้วยการทำงานพร้อมกันนั้นมีความซับซ้อนมากกว่า การทำงานพร้อมกันใน 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 รายการ เพื่อให้พร้อมใช้งาน
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 ขยายขนาดแอปเกินการตั้งค่า คุณจะพบ Cold Start สำหรับแต่ละอินสแตนซ์ที่สูงกว่าเกณฑ์นั้น
- Cold Start ส่งผลกระทบต่อแอปที่มีการเข้าชมที่ผันผวนมากที่สุด หากแอปมีการเข้าชมที่ผันผวนและคุณตั้งค่าให้สูงพอที่จะ ลดการเริ่มต้นใหม่เมื่อมีการเข้าชมเพิ่มขึ้นแต่ละครั้ง คุณจะเห็นว่าเวลาในการตอบสนอง ลดลงอย่างมาก สำหรับแอปที่มีการเข้าชมอย่างต่อเนื่อง Cold Start ไม่น่าจะส่งผลต่อประสิทธิภาพอย่างรุนแรง
การตั้งค่าอินสแตนซ์ขั้นต่ำอาจเหมาะสมกับสภาพแวดล้อมการใช้งานจริง แต่ โดยปกติแล้วควรหลีกเลี่ยงในสภาพแวดล้อมการทดสอบ หากต้องการปรับขนาดเป็น 0 ในโปรเจ็กต์ทดสอบ แต่ยังคงลดการเริ่มระบบแบบเย็นในโปรเจ็กต์ที่ใช้งานจริง คุณสามารถตั้งค่าอินสแตนซ์ขั้นต่ำในการกำหนดค่าแบบพารามิเตอร์ได้ดังนี้
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.`); } );
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 GiB และหมดเวลาหลังจาก 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
- ในคอนโซล Google Cloud ให้เลือก Cloud Functions for Firebase จากเมนูด้านซ้าย
- เลือกฟังก์ชันโดยคลิกชื่อฟังก์ชันในรายการฟังก์ชัน
- คลิกไอคอนแก้ไขในเมนูด้านบน
- เลือกการจัดสรรหน่วยความจำจากเมนูแบบเลื่อนลงที่มีป้ายกำกับว่า หน่วยความจำที่จัดสรร
- คลิกเพิ่มเติมเพื่อแสดงตัวเลือกขั้นสูง แล้วป้อนจำนวน วินาทีในกล่องข้อความหมดเวลา
- คลิกบันทึกเพื่ออัปเดตฟังก์ชัน
ลบล้างค่าเริ่มต้นของ CPU
จัดสรรหน่วยความจำสูงสุด 2 GB โดยแต่ละฟังก์ชันใน Cloud Functions for Firebase (รุ่นที่ 2) จะใช้ CPU 1 ตัวโดยค่าเริ่มต้น จากนั้นจะเพิ่มเป็น 2 CPU สำหรับ 4 GB และ 8 GB โปรดทราบว่า ลักษณะการทำงานเริ่มต้นนี้แตกต่างจากรุ่นที่ 1 อย่างมาก ซึ่งอาจ ทำให้ฟังก์ชันที่มีหน่วยความจำต่ำมีค่าใช้จ่ายสูงขึ้นเล็กน้อยตามที่ระบุไว้ในตารางต่อไปนี้
RAM ที่จัดสรร | CPU เริ่มต้นเวอร์ชัน 1 (เศษส่วน) | CPU เริ่มต้นเวอร์ชัน 2 | การขึ้นราคาต่อมิลลิวินาที |
---|---|---|---|
128MB | 1/12 | 1 | 10.5 เท่า |
256MB | 1/6 | 1 | 5.3 เท่า |
512MB | 1/3 | 1 | 2.7x |
1GB | 7/12 | 1 | 1.6x |
2GB | 1 | 1 | 1x |
4 GB | 2 | 2 | 1x |
8GB | 2 | 2 | 1x |
16 GB | ไม่มี | 4 | ไม่มี |
หากต้องการให้ฟังก์ชันรุ่นที่ 2 ทำงานเหมือนรุ่นที่ 1 ให้ตั้งค่าเริ่มต้นของรุ่นที่ 1 เป็นตัวเลือกส่วนกลางโดยทำดังนี้
// Turn off Firebase defaults
setGlobalOptions({ cpu: 'gcf_gen1' });
# Use 1st gen behavior
set_global_options(cpu="gcf_gen1")
สำหรับฟังก์ชันที่ใช้ CPU หนัก รุ่นที่ 2 จะให้ความยืดหยุ่นในการกำหนดค่า 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