Google Chat API ortak bir hizmet olduğundan, API'nin tüm kullanıcılar tarafından adil bir şekilde kullanıldığından emin olmak ve Google Workspace'in genel performansını korumak için kotalar ve sınırlamalar uygularız.
Bir kotayı aşarsanız 429: Too many requests
HTTP durum kodu yanıtı alırsınız. Chat arka ucundaki ek hız sınırı kontrolleri de aynı hata yanıtını oluşturabilir. Bu hata oluşursa üstel geri çekilme algoritması kullanmanız ve daha sonra tekrar denemeniz gerekir. Aşağıdaki tablolarda listelenen dakika başına kotaları içinde kaldığınız sürece, günlük gönderebileceğiniz istek sayısında bir sınır yoktur.
Chat API yöntemleri için iki kota türü geçerlidir: alan başına ve proje başına kotalar.
Alan başına kotalar
Alan başına kotalar, belirli bir alandaki sorguların hızını sınırlar ve her kota için listelenen Chat API yöntemlerini çağıran, ilgili alanda faaliyet gösteren tüm Chat uygulamaları arasında paylaşılır.
Aşağıdaki tabloda, alan başına sorgu sınırları ayrıntıları verilmiştir:
Alan Başına Kota |
Chat API yöntemleri |
Sınır (60 saniye başına, alandaki tüm |
---|---|---|
Dakika başına okuma sayısı |
|
900 |
Dakika başına yazma sayısı |
|
60 |
Proje başına kotalar
Proje başına kotalar, bir Google Cloud projesinde sorgu hızını sınırlandırır. Bu sayede, her kota için belirtilen Chat API yöntemlerini çağıran tek bir Chat uygulamasına uygulanır.
Aşağıdaki tabloda proje başına sorgu sınırları gösterilmiştir. Bu sınırları Kotalar sayfasında da bulabilirsiniz.
Proje Başına Kota |
Chat API yöntemleri |
Sınır (60 saniye başına) |
---|---|---|
Dakika başına ileti yazma sayısı |
|
3.000 |
Dakika başına ileti okuma sayısı |
|
3.000 |
Dakika başına üyelik yazma sayısı |
|
300 |
Dakika başına üyelik okuma sayısı |
|
3.000 |
Dakika başına alan yazma sayısı |
|
60 |
Dakika başına boşluk okuma |
|
3.000 |
Dakika başına ek yazma |
|
600 |
Dakika başına ek okuma |
|
3.000 |
Dakika başına tepki yazma sayısı |
|
600 |
Dakikada tepki okuma sayısı |
|
3.000 |
Ek kullanım sınırları
spaces.create
veya spaces.setup
yöntemini kullanarak GROUP_CHAT
veya SPACE
türünde alanlar oluşturmak için ek kota sınırları söz konusudur.
Bu türlerde dakikada 35'ten az ve saatte 210'dan az alan oluşturun. DIRECT_MESSAGE
türündeki alanlar bu ek kota sınırlarına tabi değildir.
Aynı alanı hedefleyen herhangi bir API'nin saniyedeki büyük sorguları (QPS), Kotalar sayfasında görünmeyen ek dahili sınırları tetikleyebilir.
Zamana dayalı kota hatalarını çözme
Zamana dayalı tüm hatalarda (X dakikada en fazla N istek) kodunuzun istisnayı yakalamasını ve cihazlarınızın aşırı yük oluşturmaması için kısaltılmış bir üstel geri yükleme işlemi kullanmanızı öneririz.
Üstel geri yükleme, ağ uygulamaları için standart bir hata işleme stratejisidir. Eksponansiyel geri yükleme algoritması, istekler arasında maksimum geri yükleme süresine kadar katlanarak artan bekleme sürelerini kullanarak istekleri yeniden dener. İstekler yine de başarısız olursa, istek başarılı olana kadar istekler arasındaki gecikmelerin zaman içinde artması önemlidir.
Örnek algoritma
Eksponansiyel geri yükleme algoritması, istekleri katlanarak yeniden dener. Böylece yeniden denemeler arasındaki bekleme süresi maksimum geri yükleme süresine kadar uzatılır. Örneğin:
- Google Chat API'ye istekte bulunun.
- İstek başarısız olursa 1 +
random_number_milliseconds
bekleyin ve isteği yeniden deneyin. - İstek başarısız olursa 2 +
random_number_milliseconds
bekleyin ve isteği yeniden deneyin. - İstek başarısız olursa 4 +
random_number_milliseconds
bekleyip isteği yeniden deneyin. - Bu şekilde
maximum_backoff
defaya kadar devam edebilirsiniz. - Beklemeye devam edip maksimum yeniden deneme sayısına kadar yeniden deneyebilirsiniz. Ancak yeniden denemeler arasındaki bekleme süresini uzatmayın.
Bu örnekte:
- Bekleme süresi
min(((2^n)+random_number_milliseconds), maximum_backoff)
şeklindedir ven
her iterasyon (istek) için 1 artar. random_number_milliseconds
,1.000'den küçük veya 1.000'e eşit olan rastgele bir milisaniye sayısıdır. Bu işlem, çok sayıda istemcinin bir durum nedeniyle senkronize edildiği ve tüm istemcilerin aynı anda yeniden denediği durumların önlenmesine yardımcı olur. Böylece, isteklerin senkronize dalgalar halinde gönderilmesi sağlanır.random_number_milliseconds
değeri, her yeniden deneme isteğinden sonra yeniden hesaplanır.maximum_backoff
genellikle 32 veya 64 saniyedir. Uygun değer, kullanım alanına bağlıdır.
İstemci, maximum_backoff
süresine ulaştıktan sonra yeniden denemeye devam edebilir.
Bu noktadan sonra yapılan yeniden denemelerin, geri yükleme süresini artırmaya devam etmesi gerekmez. Örneğin, bir istemci 64 saniyelik bir maximum_backoff
süresi kullanırsa bu değere ulaştıktan sonra her 64 saniyede bir yeniden deneyebilir. Bir noktada, istemcilerin yeniden denemesi süresiz olarak engellenmelidir.
Yeniden denemeler ile yeniden deneme sayısı arasındaki bekleme süresi, kullanım alanınıza ve ağ koşullarınıza bağlıdır.
Proje başına kota artışı isteme
Projenizin kaynak kullanımına bağlı olarak kota artışı talep edebilirsiniz. Bir hizmet hesabından yapılan API çağrıları, tek bir hesap kullanıyor olarak kabul edilir. Kota artışı için başvurmak, onay alacağınızı garanti etmez. Büyük kota artışlarının onaylanması daha uzun sürebilir.
Her projenin kotası aynı değildir. Google Cloud'u zaman içinde gitgide daha fazla kullandığınız için kotalarınızın da artması gerekebilir. Kullanımın önemli oranda artacağını düşünüyorsanız Google Cloud Console'daki Kotalar sayfasından önlem amaçlı olarak kotaların ayarlanmasını isteyebilirsiniz.
Daha fazla bilgi edinmek için aşağıdaki kaynakları inceleyin:
- Kota artışı istekleri hakkında
- Mevcut kota kullanımınızı ve sınırlarınızı görüntüleme
- Kota sınırını yükseltme isteğinde bulunma