ขีดจำกัดการใช้งาน

Google ปฏิทิน API มีโควต้าเพื่อให้ผู้ใช้ทุกคนใช้งานได้อย่างยุติธรรม โปรดคำนึงถึงข้อจำกัดที่สำคัญ 3 ข้อต่อไปนี้เมื่อใช้ Calendar API

• โควต้าการใช้งาน API: บังคับใช้ต่อโปรเจ็กต์และต่อผู้ใช้ ดูข้อมูลเพิ่มเติมได้ที่ ประเภทโควต้าการใช้งาน Calendar API

• ขีดจำกัดการใช้งานปฏิทินทั่วไป: Calendar API เป็นบริการที่แชร์กันซึ่งมีข้อจำกัดเพื่อปกป้องประสิทธิภาพโดยรวม ของระบบ Google Workspace ดูข้อมูลเพิ่มเติมได้ที่ หลีกเลี่ยงขีดจำกัดการใช้ปฏิทิน

• ขีดจำกัดการดำเนินการ: ระบบอาจใช้ขีดจำกัดเหล่านี้ได้ทุกเมื่อ ตัวอย่างเช่น ระบบอาจใช้ขีดจำกัดหากคุณพยายามเขียนลงในปฏิทินเดียวอย่างรวดเร็วและต่อเนื่อง

โควต้า Calendar API

ระบบจะบังคับใช้โควต้า 2 ประเภท ได้แก่

• ต่อนาทีต่อโปรเจ็กต์: จำนวนคำขอที่โปรเจ็กต์ Google Cloud ส่งได้ใน 1 นาที

• ต่อนาทีต่อผู้ใช้ต่อโปรเจ็กต์: จำนวนคำขอที่ผู้ใช้รายใดรายหนึ่งส่งได้ในโปรเจ็กต์ที่อยู่ในระบบคลาวด์ ขีดจำกัดนี้ช่วยให้มั่นใจได้ว่าการใช้งานจะกระจายไปยังผู้ใช้ต่างๆ อย่างยุติธรรม

ระบบจะคำนวณโควต้าต่อนาทีโดยใช้หน้าต่างแบบเลื่อน การรับส่งข้อมูลที่เพิ่มขึ้นอย่างรวดเร็วซึ่งเกินโควต้าต่อนาทีจะส่งผลให้มีการจำกัดอัตราในช่วงหน้าต่างถัดไป เพื่อให้การใช้งานโดยเฉลี่ยยังคงอยู่ในโควต้า

ตารางต่อไปนี้แสดงรายละเอียดขีดจำกัดเหล่านี้

ประเภทขีดจำกัดการใช้งาน	ขีดจำกัด
ต่อนาทีต่อโปรเจ็กต์	คำขอ 10,000 รายการ
ต่อนาทีต่อผู้ใช้ต่อโปรเจ็กต์	คำขอ 600 รายการ

เกณฑ์การเรียกเก็บเงินรายวัน

ขีดจำกัดต่อวันต่อโปรเจ็กต์ นี้กำหนดจำนวนคำขอสูงสุดที่โปรเจ็กต์ที่อยู่ในระบบคลาวด์ใช้ได้ภายในระยะเวลา 24 ชั่วโมงก่อนที่จะมีการเรียกเก็บเงิน

การใช้งานที่ต่ำกว่าเกณฑ์นี้จะไม่มีค่าใช้จ่ายเพิ่มเติมและระบบจะไม่เรียกเก็บเงินจากบัญชี Google Cloud เราจะแชร์รายละเอียดการเรียกเก็บเงินทั้งหมดในช่วงปลายปี 2026 โดยจะแจ้งให้ทราบล่วงหน้าอย่างน้อย 90 วันก่อนที่การเปลี่ยนแปลงจะมีผล

คุณไม่สามารถขอเพิ่มขีดจำกัดเกณฑ์รายวันได้

ตารางต่อไปนี้แสดงรายละเอียดขีดจำกัด

ประเภทขีดจำกัดเกณฑ์	ขีดจำกัด
ต่อวันต่อโปรเจ็กต์	คำขอ 1,000,000 รายการ

ดูข้อมูลเพิ่มเติมได้ที่ โมเดลมาตรฐานของ Google Workspace สำหรับเครื่องมือและ API ของตัวแทน

แก้ไขข้อผิดพลาดเกี่ยวกับโควต้าตามเวลา

สำหรับข้อผิดพลาดทั้งหมดที่อิงตามเวลา (คำขอสูงสุด N รายการต่อ X นาที) เราขอแนะนำ ให้โค้ดของคุณตรวจจับข้อยกเว้นและใช้ Exponential Backoff แบบย่อ เพื่อให้แน่ใจว่าอุปกรณ์ จะไม่สร้างภาระงานมากเกินไป

Exponential Backoff เป็นกลยุทธ์การจัดการข้อผิดพลาดมาตรฐานสำหรับแอปพลิเคชันเครือข่าย อัลกอริทึม Exponential Backoff จะลองส่งคำขออีกครั้งโดยใช้เวลารอระหว่างคำขอที่เพิ่มขึ้นแบบยกกำลัง จนถึงเวลา Backoff สูงสุด หากคำขอไม่สำเร็จ คุณควรเพิ่มความล่าช้าระหว่างคำขอเมื่อเวลาผ่านไปจนกว่าคำขอจะสำเร็จ

ตัวอย่างอัลกอริทึม

อัลกอริทึม Exponential Backoff จะลองส่งคำขออีกครั้งแบบยกกำลัง โดยเพิ่มเวลารอ ระหว่างการลองอีกครั้งจนถึงเวลา Backoff สูงสุด ตัวอย่างเช่น

1. ส่งคำขอไปยัง Google ปฏิทิน API
2. หากคำขอไม่สำเร็จ ให้รอ 1 + random_number_milliseconds แล้วลองส่งคำขออีกครั้ง
3. หากคำขอไม่สำเร็จ ให้รอ 2 + random_number_milliseconds แล้วลองส่งคำขออีกครั้ง
4. หากคำขอไม่สำเร็จ ให้รอ 4 + random_number_milliseconds แล้วลองส่งคำขออีกครั้ง
5. และอื่นๆ จนถึงเวลา maximum_backoff
6. รอและลองอีกครั้งต่อไปจนถึงจำนวนการลองอีกครั้งสูงสุด แต่ไม่ต้องเพิ่มระยะเวลารอ ระหว่างการลองอีกครั้ง

โดยที่

• เวลารอคือ min(((2^n)+random_number_milliseconds), maximum_backoff), โดย n จะเพิ่มขึ้น 1 สำหรับการทำซ้ำ (คำขอ) แต่ละครั้ง
• random_number_milliseconds คือจำนวนมิลลิวินาทีแบบสุ่มซึ่งมีค่าไม่เกิน 1,000 ซึ่งจะช่วยหลีกเลี่ยงกรณีที่ไคลเอ็นต์จำนวนมากซิงค์กันเนื่องจาก สถานการณ์บางอย่างและลองอีกครั้งพร้อมกันทั้งหมด ทำให้ส่งคำขอเป็นระลอกแบบซิงค์กัน ระบบจะคำนวณค่า random_number_milliseconds ใหม่หลังจากคำขอการลองอีกครั้งแต่ละรายการ
• maximum_backoff โดยทั่วไปคือ 32 หรือ 64 วินาที ค่าที่เหมาะสม จะขึ้นอยู่กับกรณีการใช้งาน

ไคลเอ็นต์สามารถลองอีกครั้งต่อไปได้หลังจากถึงเวลา maximum_backoff แล้ว การลองอีกครั้งหลังจากจุดนี้ไม่จำเป็นต้องเพิ่มเวลา Backoff ต่อไป ตัวอย่างเช่น หากไคลเอ็นต์ใช้เวลา maximum_backoff 64 วินาที หลังจากถึงค่านี้แล้ว ไคลเอ็นต์จะลองอีกครั้งทุกๆ 64 วินาทีได้ ไคลเอ็นต์ควรได้รับการป้องกันไม่ให้ลองอีกครั้งอย่างไม่มีกำหนด

เวลารอระหว่างการลองอีกครั้งและจำนวนการลองอีกครั้งจะขึ้นอยู่กับกรณีการใช้งาน และสภาพเครือข่าย

ราคา

การใช้งาน Google ปฏิทิน API ตามมาตรฐานทั้งหมดไม่มีค่าใช้จ่ายเพิ่มเติม การใช้งานเกินขีดจำกัดคำขอโควต้า จะมีการเรียกเก็บเงินจากบัญชีสำหรับการเรียกเก็บเงินของ Google Cloud ในช่วงปลายปี 2026 ดูข้อมูลเพิ่มเติมได้ที่ โมเดลมาตรฐานของ Google Workspace สำหรับเครื่องมือและ API ของตัวแทน

ขอเพิ่มโควต้า

คุณอาจต้องการขอปรับโควต้าตามการใช้ทรัพยากรของโปรเจ็กต์ ระบบจะถือว่าการเรียก API โดยบัญชีบริการเป็นการใช้บัญชีเดียว การขอโควต้าที่ปรับแล้วอาจไม่ได้รับการอนุมัติเสมอไป คำขอปรับโควต้าที่จะเพิ่มค่าโควต้าอย่างมากอาจใช้เวลาในการอนุมัตินานขึ้น

โปรเจ็กต์ทั้งหมดไม่ได้มีโควต้าเหมือนกัน เมื่อคุณใช้ Google Cloud มากขึ้นเรื่อยๆ ค่าโควต้าอาจต้องเพิ่มขึ้น หากคาดว่าจะมีการใช้งานเพิ่มขึ้นอย่างเห็นได้ชัดในอนาคตอันใกล้ คุณสามารถ ขอปรับโควต้า ได้ล่วงหน้าจากหน้า โควต้าและขีดจำกัดของระบบ ในคอนโซล Google Cloud

ดูข้อมูลเพิ่มเติมได้จากแหล่งข้อมูลต่อไปนี้

• เกี่ยวกับการปรับโควต้า
• ดูการใช้โควต้าและขีดจำกัด
• ขอเพิ่มขีดจำกัดโควต้า

แก้ปัญหา

หากใช้งานเกินโควต้าใดโควต้าหนึ่ง ระบบจะจำกัดอัตราและคุณจะได้รับ 403 usageLimits รหัสสถานะ หรือ 429 usageLimits รหัสสถานะ ในการตอบกลับการค้นหา

หากเกิดเหตุการณ์นี้ขึ้น คุณสามารถลองทำดังนี้

1. ตรวจสอบว่าได้ปฏิบัติตามแนวทางปฏิบัติแนะนำทั้งหมดแล้ว ได้แก่ ใช้ Exponential Backoff, สุ่มรูปแบบการรับส่งข้อมูล, และใช้ ข้อความ Push

2. หากโปรเจ็กต์เติบโตขึ้นและมีผู้ใช้มากขึ้น คุณสามารถขอเพิ่มโควต้า ได้

3. หากใช้งานถึงขีดจำกัดโควต้าต่อผู้ใช้แล้ว คุณสามารถทำดังนี้

   • หากใช้บัญชีบริการ ให้จัดสรรภาระงานให้กับ ผู้ใช้ หรือแบ่งภาระงานระหว่างบัญชีบริการหลายบัญชี

   • แม้ว่าคุณจะขอเพิ่มโควต้าต่อผู้ใช้ได้ แต่โดยทั่วไปแล้วเราไม่แนะนำให้เพิ่มโควต้าสูงกว่าค่าเริ่มต้น เนื่องจากแอปพลิเคชันอาจใช้งานถึงขีดจำกัดประเภทอื่นๆ เช่น ขีดจำกัดการใช้งานปฏิทินทั่วไปหรือขีดจำกัดการดำเนินการ

4. ทดสอบขีดจำกัดโควต้าโดยลงทะเบียนโปรเจ็กต์ทดสอบแยกต่างหากที่มีการกำหนดค่าคล้ายกับโปรเจ็กต์ที่ใช้งานจริง ดูข้อมูลเพิ่มเติมได้ที่ ดู ทดสอบการจัดการขีดจำกัดโควต้า

สุ่มรูปแบบการรับส่งข้อมูล

ไคลเอ็นต์ปฏิทินมีแนวโน้มที่จะมีการรับส่งข้อมูลเพิ่มขึ้นอย่างรวดเร็วและไม่สม่ำเสมอเนื่องจากไคลเอ็นต์หลายรายดำเนินการพร้อมกัน ตัวอย่างเช่น แนวทางปฏิบัติที่ไม่ดีที่พบบ่อยสำหรับไคลเอ็นต์ปฏิทินคือการซิงค์แบบเต็มรูปแบบตอนเที่ยงคืน ซึ่งมักจะเกินโควต้าต่อนาทีและทำให้เกิดการจำกัดอัตราคำขอและการ Backoff

เพื่อหลีกเลี่ยงปัญหานี้ ให้กระจายการรับส่งข้อมูลตลอดทั้งวันทุกที่ที่ทำได้ หากไคลเอ็นต์ต้องทำการซิงค์รายวัน ให้ไคลเอ็นต์กำหนดเวลาแบบสุ่ม (แตกต่างกันสำหรับไคลเอ็นต์แต่ละราย) หากคุณต้องดำเนินการเป็นประจำ ให้เปลี่ยนช่วงเวลา ±25% ซึ่งจะกระจายการรับส่งข้อมูลอย่างสม่ำเสมอมากขึ้นและมอบประสบการณ์การใช้งานที่ดียิ่งขึ้น

ใช้ข้อความ Push

กรณีการใช้งานที่พบบ่อยคือการดำเนินการเมื่อใดก็ตามที่มีการเปลี่ยนแปลงในปฏิทินของผู้ใช้ รูปแบบที่ไม่แนะนำที่นี่คือการโพลปฏิทินที่สนใจซ้ำๆ ซึ่งจะทำให้โควต้าหมดลงอย่างรวดเร็ว ตัวอย่างเช่น หากแอปพลิเคชันมีผู้ใช้ 5,000 รายและโพลปฏิทินของผู้ใช้แต่ละราย 1 ครั้งต่อนาที การดำเนินการนี้จะต้องใช้โควต้าต่อนาทีอย่างน้อย 5,000 รายการ แม้ว่าจะยังไม่ได้ดำเนินการใดๆ ก็ตาม

แอปพลิเคชันฝั่งเซิร์ฟเวอร์สามารถลงทะเบียนเพื่อรับข้อความ Push ซึ่งจะช่วยให้ปฏิทินแจ้งให้คุณทราบเมื่อมีสิ่งที่คุณสนใจเกิดขึ้น การตั้งค่าเหล่านี้ต้องใช้ความพยายามมากขึ้น แต่จะช่วยให้คุณใช้โควต้าได้อย่างมีประสิทธิภาพมากขึ้นและมอบประสบการณ์การใช้งานที่ดียิ่งขึ้น ระบุ eventType ที่คุณต้องการรับการแจ้งเตือน ดูข้อมูลเพิ่มเติมได้ที่ ข้อความ Push แจ้งเตือน

การจัดสรรที่เหมาะสมด้วยบัญชีบริการ

หากแอปพลิเคชันส่งคำขอโดยใช้การมอบสิทธิ์ ทั่วทั้งโดเมน โดย ค่าเริ่มต้น ระบบจะเรียกเก็บเงินจาก บัญชีบริการตามโควต้า "ต่อนาทีต่อผู้ใช้ต่อ โปรเจ็กต์" ไม่ใช่ผู้ใช้ที่คุณกำลังแอบอ้าง ซึ่งหมายความว่าบัญชีบริการมีแนวโน้มที่จะใช้โควต้าจนหมดและถูกจำกัดอัตรา แม้ว่าบัญชีบริการอาจดำเนินการในปฏิทินของผู้ใช้หลายรายก็ตาม

คุณสามารถหลีกเลี่ยงปัญหานี้ได้โดยใช้อาร์กิวเมนต์ quotaUser ใน URL (หรือส่วนหัว HTTP x-goog-quota-user) เพื่อระบุผู้ใช้ที่จะถูกเรียกเก็บเงิน Google จะใช้พารามิเตอร์นี้สำหรับการคำนวณโควต้าเท่านั้น ดูข้อมูลเพิ่มเติมได้ที่ การจำกัด คำขอต่อ ผู้ใช้

ทดสอบการจัดการขีดจำกัดโควต้า

ทดสอบแอปพลิเคชันในสภาพแวดล้อมที่สมจริงเพื่อให้แน่ใจว่าแอปพลิเคชันจะจัดการกับการใช้งานถึงขีดจำกัดโควต้าได้อย่างราบรื่น ในการใช้งานจริง (เช่น ผ่านการลองอีกครั้งด้วย Exponential Backoff) และเพื่อลดการรบกวนที่อาจเกิดขึ้นกับผู้ ใช้

หากต้องการทดสอบโดยไม่รบกวนการใช้งานแอปพลิเคชันจริง ให้ลงทะเบียนโปรเจ็กต์ทดสอบแยกต่างหากในคอนโซล Google Cloud แล้วกำหนดค่าหน้าจอขอความยินยอม OAuthในลักษณะที่คล้ายกับโปรเจ็กต์ที่ใช้งานจริง จากนั้นคุณสามารถตั้งค่าขีดจำกัดโควต้า ต่ำอย่างไม่สมเหตุสมผลสำหรับโปรเจ็กต์นี้และสังเกตลักษณะการทำงาน ของแอปพลิเคชันได้

โควต้าเซิร์ฟเวอร์ MCP ของปฏิทิน

เซิร์ฟเวอร์ MCP ของปฏิทินใช้เมตริกการจัดสรรต้นทุนการค้นหา ตารางต่อไปนี้แสดงรายละเอียดต้นทุนการค้นหาสำหรับเมธอดเซิร์ฟเวอร์ MCP ของปฏิทินแต่ละรายการตามส่วน

โควต้า MCP ของปฏิทิน

ระบบจะบังคับใช้โควต้า 2 ประเภท ได้แก่

• ต่อนาทีต่อโปรเจ็กต์: ต้นทุนการค้นหาสำหรับโปรเจ็กต์ที่อยู่ในระบบคลาวด์ใน 1 นาที

• ต่อนาทีต่อผู้ใช้ต่อโปรเจ็กต์: ต้นทุนการค้นหาที่ผู้ใช้รายใดรายหนึ่งในโปรเจ็กต์ที่อยู่ในระบบคลาวด์อาจเกิดขึ้นใน 1 นาที

ตารางต่อไปนี้แสดงรายละเอียดโควต้าเหล่านี้

ประเภทขีดจำกัดการใช้งาน	ต้นทุนการค้นหา
ต่อนาทีต่อโปรเจ็กต์	10,000
ต่อนาทีต่อผู้ใช้ต่อโปรเจ็กต์	600

โควต้าชุดเครื่องมือ MCP ของปฏิทิน

ตารางต่อไปนี้แสดงรายละเอียดต้นทุนการค้นหาสำหรับชุดเครื่องมือ calendarmcp.googleapis.com แต่ละชุด

ปลายทาง	เครื่องมือ	ต้นทุนการค้นหา
/mcp/v1	create_event	1
	delete_event	10
	get_event	1
	list_events	1
	respond_to_event	1
	search_events	1
	update_event	1
	suggest_time	1
	list_calendars	1

ดูข้อมูลเพิ่มเติมได้ที่ข้อมูลอ้างอิง Calendar MCP API

หัวข้อที่เกี่ยวข้อง

• ส่งคำขอเป็นชุด
• ปรับปรุงประสิทธิภาพ
• หลีกเลี่ยงขีดจำกัดการใช้ปฏิทิน