Google ปฏิทิน API มีโควต้าเพื่อให้มั่นใจว่าผู้ใช้ทุกคนจะใช้งานได้อย่างเท่าเทียมกัน ข้อจำกัดสำคัญ 3 ประการที่ควรพิจารณาเมื่อใช้ Calendar API มีดังนี้
โควต้าการใช้งาน 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 สูงสุด เช่น
- ส่งคำขอไปยัง Google ปฏิทิน API
- หากคำขอไม่สำเร็จ ให้รอ 1 +
random_number_millisecondsแล้วลองส่งคำขออีกครั้ง - หากคำขอไม่สำเร็จ ให้รอ 2 +
random_number_millisecondsแล้วลองส่งคำขออีกครั้ง - หากคำขอไม่สำเร็จ ให้รอ 4 +
random_number_millisecondsแล้วลองส่งคำขออีกครั้ง - และอื่นๆ สูงสุด
maximum_backoffครั้ง - รอและลองอีกครั้งต่อไปจนกว่าจะถึงจำนวนครั้งสูงสุดที่ลองใหม่ได้ แต่ไม่ต้องเพิ่มระยะเวลารอ ระหว่างการลองใหม่
where:
- เวลารออยู่ที่
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
ในการตอบกลับคำค้นหา
หากเกิดกรณีนี้ขึ้น คุณสามารถลองทำดังนี้
โปรดปฏิบัติตามแนวทางปฏิบัติแนะนำทั้งหมด ได้แก่ ใช้การถอยแบบ ทวีคูณ สุ่มรูปแบบการเข้าชม และใช้การแจ้งเตือนแบบพุช
หากโปรเจ็กต์เติบโตขึ้นและมีผู้ใช้มากขึ้น คุณสามารถขอเพิ่มโควต้าได้
หากถึงขีดจำกัดโควต้าต่อผู้ใช้แล้ว คุณจะทำสิ่งต่อไปนี้ได้
หากใช้บัญชีบริการ ให้จัดสรรภาระงานให้กับผู้ใช้หรือแบ่งภาระงานระหว่างบัญชีบริการหลายบัญชี
แม้ว่าคุณจะขอเพิ่มโควต้าต่อผู้ใช้ได้ แต่โดยทั่วไปแล้ว เราไม่แนะนำให้เพิ่มโควต้าให้สูงกว่าค่าเริ่มต้น เนื่องจากแอปพลิเคชัน อาจเริ่มใช้งานถึงขีดจำกัดประเภทอื่นๆ เช่น ขีดจำกัดการใช้งานปฏิทินทั่วไปหรือขีดจำกัดด้านการดำเนินงาน
ทดสอบขีดจํากัดโควต้าโดยการลงทะเบียนโปรเจ็กต์ทดสอบแยกต่างหากที่มี การกําหนดค่าคล้ายกับโปรเจ็กต์เวอร์ชันที่ใช้งานจริง ดูข้อมูลเพิ่มเติมได้ที่การจัดการขีดจำกัดโควต้าทดสอบ
สุ่มรูปแบบการเข้าชม
ไคลเอ็นต์ปฏิทินมีแนวโน้มที่จะมีรูปแบบการเข้าชมที่ผันผวนเนื่องจาก ไคลเอ็นต์หลายรายดำเนินการพร้อมกัน ตัวอย่างเช่น แนวทางปฏิบัติที่ไม่ดีที่พบบ่อยสำหรับไคลเอ็นต์ปฏิทินคือการซิงค์แบบเต็มที่เวลาเที่ยงคืน ซึ่งเกือบทั้งหมดจะทำให้คุณใช้โควต้าต่อนาทีเกิน และส่งผลให้มีการจำกัดอัตราและการหยุดชั่วคราว
โปรดกระจายการเข้าชมตลอดทั้งวันทุกที่ที่เป็นไปได้เพื่อหลีกเลี่ยงปัญหานี้ หากลูกค้าต้องซิงค์ทุกวัน ให้ลูกค้ากำหนดเวลาแบบสุ่ม (แตกต่างกันสำหรับลูกค้าแต่ละราย) หากต้องการดำเนินการเป็นประจำ ให้เปลี่ยนช่วงเวลา +/- 25% ซึ่งจะช่วยกระจายการเข้าชม ให้สม่ำเสมอมากขึ้นและมอบประสบการณ์การใช้งานที่ดียิ่งขึ้นให้แก่ผู้ใช้
ใช้ข้อความ Push
Use Case ทั่วไปคือการดำเนินการเมื่อใดก็ตามที่มีการเปลี่ยนแปลงในปฏิทินของผู้ใช้ รูปแบบที่ไม่ควรทำในที่นี้คือการสำรวจปฏิทินทุกรายการที่คุณสนใจซ้ำๆ ซึ่งจะทำให้โควต้าของคุณหมดลงอย่างรวดเร็ว ตัวอย่างเช่น หากแอปพลิเคชันมีผู้ใช้ 5,000 คนและสำรวจปฏิทินของผู้ใช้แต่ละคนทุกๆ 1 นาที คุณจะต้องมีโควต้าต่อนาทีอย่างน้อย 5,000 รายการ แม้ว่าจะยังไม่ได้ดำเนินการใดๆ ก็ตาม
แอปพลิเคชันฝั่งเซิร์ฟเวอร์สามารถลงทะเบียนเพื่อรับข้อความ Push ซึ่งจะช่วยให้เรา
แจ้งให้คุณทราบเมื่อมีสิ่งที่คุณสนใจเกิดขึ้น แม้ว่าการตั้งค่าจะต้องใช้เวลามากขึ้น แต่จะช่วยให้คุณใช้โควต้าได้อย่างมีประสิทธิภาพมากขึ้นอย่างมาก และมอบประสบการณ์การใช้งานที่ดีขึ้น ตรวจสอบว่าคุณได้ระบุ eventType ที่ต้องการรับการแจ้งเตือน ดูข้อมูลเพิ่มเติมได้ที่ข้อความพุช
การจัดสรรที่เหมาะสมด้วยบัญชีบริการ
หากแอปพลิเคชันของคุณส่งคำขอโดยใช้การมอบสิทธิ์ระดับโดเมน โดยค่าเริ่มต้น ระบบจะเรียกเก็บเงินจากบัญชีบริการตามโควต้า "ต่อนาทีต่อผู้ใช้ต่อ โปรเจ็กต์" ไม่ใช่ผู้ใช้ที่คุณแอบอ้าง ซึ่งหมายความว่าบัญชีบริการมีแนวโน้มที่จะใช้โควต้าจนหมดและถูกจำกัดอัตรา แม้ว่าบัญชีบริการอาจทำงานในปฏิทินของผู้ใช้หลายรายก็ตาม
คุณสามารถหลีกเลี่ยงปัญหานี้ได้โดยใช้quotaUserพารามิเตอร์ URL (หรือส่วนหัว HTTP
x-goog-quota-user) เพื่อระบุผู้ใช้ที่จะเรียกเก็บเงิน โดยจะใช้
สำหรับการคำนวณโควต้าเท่านั้น ดูข้อมูลเพิ่มเติมได้ที่การจำกัดคำขอต่อ
ผู้ใช้
ทดสอบการจัดการขีดจำกัดโควต้า
เพื่อให้แน่ใจว่าแอปพลิเคชันของคุณจะจัดการกับการเข้าถึงโควต้าได้อย่างราบรื่น ในทางปฏิบัติ (เช่น ผ่านการลองใหม่ด้วย การเพิ่มเวลาหน่วงแบบทวีคูณ) และเพื่อลดการรบกวนที่อาจเกิดขึ้นกับผู้ใช้ เราขอแนะนำอย่างยิ่งให้ทดสอบสถานการณ์ในสภาพแวดล้อมจริง
หากต้องการทดสอบโดยไม่รบกวนการใช้งานแอปพลิเคชันจริง เราขอแนะนำให้ลงทะเบียนโปรเจ็กต์ทดสอบแยกต่างหากในคอนโซล Google Cloud แล้วกำหนดค่าหน้าจอขอความยินยอม OAuth ในลักษณะเดียวกับโปรเจ็กต์เวอร์ชันที่ใช้งานจริง จากนั้นคุณจะตั้งค่าขีดจำกัดโควต้า ต่ำเทียมสำหรับโปรเจ็กต์นี้และสังเกต ลักษณะการทำงานของแอปพลิเคชันได้