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

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

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

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

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

โควต้าต่อพื้นที่ทำงานจะจำกัดอัตราการค้นหาในพื้นที่ทำงานหนึ่งๆ และจะแชร์กับแอป 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	3,000
จำนวนข้อความต่อนาที	spaces.messages.get spaces.messages.list	3,000
การเขียนการเป็นสมาชิกต่อนาที	spaces.members.create spaces.members.delete	300
การอ่านของสมาชิกต่อนาที	spaces.members.get spaces.members.list	3,000
การเขียนเว้นวรรคต่อนาที	spaces.setup spaces.create spaces.patch spaces.delete	60
การอ่านพื้นที่ทำงานต่อนาที	spaces.get spaces.list spaces.findDirectMessage	3,000
การเขียนไฟล์แนบต่อนาที	media.upload	600
การอ่านไฟล์แนบต่อนาที	spaces.messages.attachments.get media.download	3,000
การเขียนความรู้สึกต่อนาที	spaces.messages.reactions.create spaces.messages.reactions.delete	600
จำนวนรีแอ็กชันต่อนาที	spaces.messages.reactions.list	3,000

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

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

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

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

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

Exponential Backoff เป็นกลยุทธ์การจัดการข้อผิดพลาดมาตรฐานสำหรับแอปพลิเคชันเครือข่าย อัลกอริทึม 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 ครั้งแล้ว ลองใหม่หลังจากจุดนี้ไม่จําเป็นต้องเพิ่มเวลา Backoff อีก เช่น หากลูกค้าใช้เวลา maximum_backoff นาน 64 วินาที หลังจากถึงค่านี้แล้ว ไคลเอ็นต์จะลองซ้ำได้ทุกๆ 64 วินาที ในบางสถานการณ์ ไคลเอ็นต์ควรถูกป้องกันไม่ให้ลองอีกครั้งไปเรื่อยๆ

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

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

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

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

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

• เกี่ยวกับคำขอเพิ่มโควต้า
• ดูการใช้งานและขีดจำกัดโควต้าปัจจุบัน
• ขอเพิ่มขีดจำกัดโควต้า