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

เนื่องจาก Google Workspace Events API เป็นบริการที่ใช้ร่วมกัน เราจึงใช้โควต้าและข้อจำกัดเพื่อดูแลให้ผู้ใช้ทุกคนใช้งานอย่างเป็นธรรม และเพื่อปกป้องประสิทธิภาพโดยรวมของ Google Workspace

หากใช้เกินโควต้า คุณจะได้รับการตอบกลับรหัสสถานะ HTTP 429: Too many requests การตรวจสอบขีดจำกัดอัตราเพิ่มเติมในแบ็กเอนด์ Google Workspace Events API อาจสร้างการตอบสนองข้อผิดพลาดแบบเดียวกันด้วย หากเกิดข้อผิดพลาดขึ้น คุณควรใช้อัลกอริทึม Backoff แบบเอ็กซ์โปเนนเชียลแล้วลองอีกครั้งในภายหลัง ตราบใดที่คุณยังอยู่ภายในโควต้าต่อนาทีที่แสดงในตารางต่อไปนี้ เราจะไม่จำกัดจำนวนคำขอที่คุณสามารถสร้างได้ใน 1 วัน

โควต้าต่อโปรเจ็กต์

โควต้าต่อโปรเจ็กต์จะจำกัดอัตราการค้นหาสำหรับโปรเจ็กต์ Google Cloud ดังนั้นจึงใช้กับแอปเดียวที่เรียกใช้เมธอด Google Workspace Events API ที่ระบุสำหรับโควต้าแต่ละรายการ

ตารางต่อไปนี้จะแสดงรายละเอียดขีดจำกัดการค้นหาต่อโปรเจ็กต์ คุณดูขีดจำกัดเหล่านี้ได้ในหน้าโควต้าในคอนโซล Google Cloud

โควต้าต่อโปรเจ็กต์

เมธอด Google Workspace Events API

ขีดจำกัด

การเขียนต่อนาที

Subscriptions.create

Subscriptions.patch

Subscriptions.delete

Subscriptions.reactivate

600

การเขียนต่อนาทีต่อผู้ใช้

Subscriptions.create

Subscriptions.patch

Subscriptions.delete

Subscriptions.reactivate

100

การอ่านต่อนาที

Subscriptions.get

Subscriptions.list

600

การอ่านต่อนาทีต่อผู้ใช้

Subscriptions.get

Subscriptions.list

100

แก้ไขข้อผิดพลาดด้านโควต้าตามเวลา

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

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

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

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

  1. ส่งคำขอไปยัง Google Workspace Events 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 วินาที ในบางสถานการณ์ ควรป้องกันไม่ให้ไคลเอ็นต์ลองอีกครั้งอย่างไม่มีกำหนด

เวลารอระหว่างการลองใหม่และจำนวนการทดลองซ้ำจะขึ้นอยู่กับกรณีการใช้งานและเงื่อนไขของเครือข่าย

ขอเพิ่มโควต้าต่อโปรเจ็กต์

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

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

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