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

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

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

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

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

โควต้า Calendar API

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

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

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

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

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

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

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

ขีดจำกัดต่อวันต่อโปรเจ็กต์ นี้กำหนดจำนวนคำขอสูงสุดที่โปรเจ็กต์ที่อยู่ในระบบคลาวด์ Google ใช้ได้ภายในระยะเวลา 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, สุ่มรูปแบบการเข้าชม และใช้ การแจ้งเตือนแบบพุช

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

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

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

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

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

สุ่มรูปแบบการเข้าชม

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

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

ใช้การแจ้งเตือนแบบพุช

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

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

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

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

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

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

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

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

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

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

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

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

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

• ต่อนาทีต่อผู้ใช้ต่อโปรเจ็กต์: ต้นทุนการค้นหาสำหรับโปรเจ็กต์ Google Cloud ใน 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

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

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