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