เนื่องจาก Google Workspace Events API เป็นบริการที่แชร์ เราจึงใช้โควต้าและข้อจำกัดเพื่อให้ผู้ใช้ทุกคนใช้งานได้อย่างยุติธรรมและเพื่อปกป้องประสิทธิภาพโดยรวมของ Google Workspace
หากคุณใช้โควต้าเกิน ระบบจะแสดงการตอบกลับรหัสสถานะ HTTP 429: Too many requests นอกจากนี้ การตรวจสอบการจำกัดอัตราเพิ่มเติมในแบ็กเอนด์ของ Google Workspace Events API อาจสร้างการตอบกลับข้อผิดพลาดเดียวกัน หากเกิดข้อผิดพลาดนี้ ให้ใช้อัลกอริทึม
Exponential Backoff
แล้วลองอีกครั้งในภายหลัง ตราบใดที่คุณยังคงอยู่ในโควต้าต่อนาทีที่ระบุไว้ในตารางต่อไปนี้ ระบบจะไม่จำกัดจำนวนคำขอที่คุณส่งได้ต่อวัน
โควต้าต่อโปรเจ็กต์
โควต้าต่อโปรเจ็กต์จะจำกัดอัตราการค้นหาสำหรับโปรเจ็กต์ Google Cloud จึงมีผลกับแอปเดียวที่เรียกใช้เมธอด Google Workspace Events API ที่ระบุสำหรับโควต้าแต่ละรายการ
ตารางต่อไปนี้แสดงรายละเอียดขีดจำกัดการค้นหาต่อโปรเจ็กต์ นอกจากนี้ คุณยังดู ขีดจำกัดเหล่านี้ได้ในหน้าโควต้าใน คอนโซล Google Cloud
โควต้าต่อโปรเจ็กต์ |
เมธอด Google Workspace Events API |
ขีดจำกัด |
|---|---|---|
การเขียนต่อนาที |
|
600 |
การเขียนต่อนาทีต่อผู้ใช้ |
|
100 |
การอ่านต่อนาที |
|
600 |
การอ่านต่อนาทีต่อผู้ใช้ |
|
100 |
แก้ไขข้อผิดพลาดเกี่ยวกับโควต้าตามเวลา
สำหรับข้อผิดพลาดทั้งหมดที่อิงตามเวลา (คำขอสูงสุด N รายการต่อ X นาที) เราขอแนะนำ ให้โค้ดของคุณดักจับข้อยกเว้นและใช้ Exponential Backoff แบบย่อ เพื่อให้แน่ใจว่าอุปกรณ์ จะไม่สร้างโหลดมากเกินไป
Exponential Backoff เป็นกลยุทธ์การจัดการข้อผิดพลาดมาตรฐานสำหรับแอปพลิเคชันเครือข่าย อัลกอริทึม Exponential Backoff จะลองส่งคำขออีกครั้งโดยใช้เวลาในการรอที่เพิ่มขึ้นแบบทวีคูณ ระหว่างคำขอ โดยรอสูงสุดตามเวลา Backoff สูงสุด หากคำขอไม่สำเร็จ คุณควรเพิ่มความล่าช้าระหว่างคำขอเมื่อเวลาผ่านไปจนกว่าคำขอจะสำเร็จ
อัลกอริทึมตัวอย่าง
อัลกอริทึม Exponential Backoff จะลองส่งคำขออีกครั้งแบบทวีคูณ โดยเพิ่มเวลาในการรอ ระหว่างการลองอีกครั้งสูงสุดตามเวลา Backoff สูงสุด เช่น
- ส่งคำขอไปยัง Google Workspace Events API
- หากคำขอไม่สำเร็จ ให้รอ 1 +
random_number_millisecondsแล้วลองส่งคำขออีกครั้ง - หากคำขอไม่สำเร็จ ให้รอ 2 +
random_number_millisecondsแล้วลองส่งคำขออีกครั้ง - หากคำขอไม่สำเร็จ ให้รอ 4 +
random_number_millisecondsแล้วลองส่งคำขออีกครั้ง - และอื่นๆ ไปเรื่อยๆ จนถึงเวลา
maximum_backoff - รอและลองอีกครั้งต่อไปจนถึงจำนวนการลองอีกครั้งสูงสุด แต่ไม่ต้องเพิ่มระยะเวลารอ ระหว่างการลองอีกครั้ง
โดยที่
- เวลาในการรอคือ
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 วินาทีได้ อย่างไรก็ตาม คุณควรป้องกันไม่ให้ไคลเอ็นต์ลองอีกครั้งอย่างไม่มีกำหนด
เวลาในการรอระหว่างการลองอีกครั้งและจำนวนการลองอีกครั้งจะขึ้นอยู่กับกรณีการใช้งาน และสภาพเครือข่าย
ขอเพิ่มโควต้าต่อโปรเจ็กต์
คุณอาจต้องการขอปรับโควต้า ตามการใช้ทรัพยากรของโปรเจ็กต์ ระบบจะถือว่าการเรียก API โดยบัญชีบริการเป็นการใช้บัญชี เดียว การขอโควต้าที่ปรับแล้วอาจไม่ได้รับการอนุมัติเสมอไป คำขอปรับโควต้า ที่จะเพิ่มค่าโควต้าอย่างมากอาจใช้เวลาในการอนุมัตินานขึ้น
โปรเจ็กต์ทั้งหมดอาจมีโควต้าไม่เท่ากัน เมื่อคุณใช้ Google Cloud มากขึ้นเรื่อยๆ ค่าโควต้าอาจต้องเพิ่มขึ้น หากคาดว่าจะมีการใช้งานเพิ่มขึ้นอย่างเห็นได้ชัดในอนาคต คุณสามารถขอปรับโควต้าล่วงหน้าได้จากหน้าโควต้าในคอนโซล Google Cloud
ดูข้อมูลเพิ่มเติมได้ที่แหล่งข้อมูลต่อไปนี้