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

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

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

โควต้า 2 ประเภทมีผลกับเมธอด Chat API ได้แก่ ต่อพื้นที่ทำงานและต่อโปรเจ็กต์ โควต้า

โควต้าต่อพื้นที่ทำงาน

โควต้าต่อพื้นที่จะจำกัดอัตราการค้นหาในพื้นที่หนึ่งๆ และจะแชร์กันระหว่าง แอป Chat ทั้งหมดที่ดำเนินการในพื้นที่นั้นซึ่งเรียกใช้ เมธอด Chat API สำหรับโควต้าแต่ละรายการ

ขีดจำกัดการค้นหาต่อพื้นที่ทำงานในรายละเอียดตารางต่อไปนี้

โควต้าต่อพื้นที่

เมธอด Chat API

ขีดจำกัด (ต่อ 60 วินาที แชร์
ในแอป Chat ทั้งหมดในพื้นที่ทำงาน)

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

media.download

spaces.get

spaces.members.get

spaces.members.list

spaces.messages.get

spaces.messages.list

spaces.messages.attachments.get

spaces.messages.reactions.list

900

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

media.upload

spaces.delete

spaces.patch

spaces.messages.create (มีผลกับเว็บฮุคขาเข้าด้วย)

spaces.messages.delete

spaces.messages.patch

spaces.messages.reactions.create

spaces.messages.reactions.delete

60

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

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

ขีดจํากัดการค้นหาต่อโปรเจ็กต์มีรายละเอียดตารางต่อไปนี้ นอกจากนี้ คุณยังค้นหา ขีดจำกัดเหล่านี้ในหน้าโควต้า

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

เมธอด Chat API

ขีดจำกัด (ต่อ 60 วินาที)

จำนวนการเขียนข้อความต่อนาที

spaces.messages.create

spaces.messages.patch

spaces.messages.delete

3000

จำนวนข้อความที่อ่านต่อนาที

spaces.messages.get

spaces.messages.list

3000

การเขียนการเป็นสมาชิกต่อนาที

spaces.members.create

spaces.members.delete

300

การอ่านการเป็นสมาชิกต่อนาที

spaces.members.get

spaces.members.list

3000

การเขียนในพื้นที่ทำงานต่อนาที

spaces.setup

spaces.create

spaces.patch

spaces.delete

60

จำนวนการอ่านพื้นที่ทำงานต่อนาที

spaces.get

spaces.list

spaces.findDirectMessage

3000

การเขียนไฟล์แนบต่อนาที

media.upload

600

จำนวนไฟล์แนบที่อ่านต่อนาที

spaces.messages.attachments.get

media.download

3000

จำนวนการเขียนรีแอ็กชันต่อนาที

spaces.messages.reactions.create

spaces.messages.reactions.delete

600

จำนวนการอ่านรีแอ็กชันต่อนาที

spaces.messages.reactions.list

3000

ขีดจำกัดการใช้งานเพิ่มเติม

มีขีดจำกัดโควต้าเพิ่มเติมสำหรับการสร้างพื้นที่ทำงานประเภท GROUP_CHAT หรือ SPACE (โดยใช้เมธอด spaces.create หรือ spaces.setup) สร้างพื้นที่ทำงานน้อยกว่า 35 ช่องต่อนาทีและไม่เกิน 210 ช่องต่อนาที ชั่วโมงของชิ้นงานประเภทนี้ พื้นที่ทำงานประเภท DIRECT_MESSAGE ไม่อยู่ภายใต้ ขีดจำกัดโควต้าเพิ่มเติม

คำค้นหาขนาดใหญ่ต่อวินาที (QPS) ของ API ที่กำหนดเป้าหมายไปยังพื้นที่เดียวกันอาจทำให้เกิดทริกเกอร์ ขีดจำกัดภายในเพิ่มเติมที่ไม่แสดงใน โควต้า

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

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

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

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

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

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

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

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

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

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

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