Hız sınırları

Google Ads API, hem müşteri kimliklerinde hem de Google Cloud projelerinde saniyedeki sorgu sayısına (QPS) göre sıklık sınırlaması uygular. Google Ads API, dakika başına istek sayısının (API çağrılarının sıklığını ölçer) yanı sıra dakika başına işlem sayısına (istekler genelindeki toplam API işlemlerinin sayısını ölçer) da sınırlama getirir. Google Ads API, istekleri ölçmek ve uygun bir QPS sınırı belirlemek için jeton paketi algoritması kullanır. Bu nedenle, tam sınır herhangi bir zamanda genel sunucu yüküne bağlı olarak değişir.

Sıklık sınırlamaları, bir kullanıcının Google Ads API sunucularını yüksek hacimli isteklerle (kasıtlı veya kasıtsız olarak) bunaltarak diğer kullanıcıların hizmetini kesintiye uğratmasını önlemek için uygulanır.

Sıklık sınırlarını ihlal eden istekler şu hatayla reddedilir: RESOURCE_TEMPORARILY_EXHAUSTED.

İstemci tarafında hem istek sayısını etkin bir şekilde azaltarak hem de QPS'yi kısıtlayarak uygulamanızın kontrolünü elinize alabilir ve sıklık sınırlarını azaltabilirsiniz.

Sıklık sınırlamasını aşma olasılığını azaltmanın birkaç yolu vardır. Mesajlaşma, yeniden teslimat ve kısıtlama gibi Kurumsal Entegrasyon Kalıpları (EIP) kavramlarını öğrenmek, daha sağlam bir istemci uygulaması oluşturmanıza yardımcı olabilir.

Aşağıdaki önerilen uygulamalar karmaşıklığa göre sıralanmıştır. En basit stratejiler en üstte, daha sağlam ancak karmaşık mimariler ise daha sonra yer alır:

Eksponansiyel geri yükleme

Uygulamanız RESOURCE_TEMPORARILY_EXHAUSTED hatası aldığında, başarısız isteği yeniden denemeden önce rastgele gecikme içeren bir eksponansiyel geri yükleme politikası kullanın. Eksponansiyel geri yükleme, yeniden denemeler arasındaki bekleme süresini kademeli olarak artırır (örneğin, 2 saniye, ardından 4 saniye, ardından 8 saniye ve küçük bir rastgele gecikme süresi). Bu sayede, istemci örnekleri arasında senkronize yeniden deneme artışları önlenirken sunucu yükü ve kota grupları kurtarılır.

Eşzamanlı görevleri sınırlama

Sıklık sınırlarının aşılmasının temel nedenlerinden biri, istemci uygulamasının aşırı sayıda paralel görev oluşturmasıdır. İstemci uygulamasının yapabileceği paralel istek sayısını sınırlamasak da bu sayı, Google Cloud projesi düzeyindeki saniye başına istek sınırını aşabilir.

İstek gönderecek eşzamanlı görevlerin toplam sayısı için (tüm işlemler ve makineler genelinde) makul bir üst sınır belirlemeniz ve sıklık sınırlamasını aşmadan işleme hızınızı optimize etmek için bu sınırı yukarı doğru ayarlamanız önerilir.

Ayrıca, istemci tarafında QPS'yi kısıtlamayı da düşünebilirsiniz (Kısıtlama ve sıklık sınırlayıcılar bölümüne bakın).

İstekleri gruplama

Birden fazla işlemi tek bir istekte birleştirmeyi deneyin. Bu, çeşitli hizmetler için yapılan Mutate aramalarında en çok geçerlidir. Örneğin, birden fazla AdGroupAd örneğinin durumunu güncelliyorsanız her AdGroupAd için bir kez MutateAdGroupAds yöntemini çağırmak yerine MutateAdGroupAds yöntemini bir kez çağırıp birden fazla operations iletebilirsiniz. Daha fazla örnek için toplu işlemlerle ilgili kılavuzumuzu inceleyin.

İstekleri toplu olarak göndermek, toplam API çağrısı sayısını azaltır ve dakika başına istek sıklık sınırlarını hafifletir. Ancak tek bir hesapta çok sayıda işlem gerçekleştirirseniz dakika başına işlem sıklık sınırını tetikleyebilir.

Kısıtlama ve sıklık sınırlayıcılar

Uygulamanızdaki toplam iş parçacığı sayısını sınırlamanın yanı sıra istemci tarafında sıklık sınırlayıcılar da uygulayabilirsiniz. Bu sayede, işlemlerinizdeki, kümelerinizdeki veya her ikisindeki tüm iş parçacıkları, istemci tarafındaki belirli bir Saniye Başına Sorgu Sayısı (QPS) sınırına tabi olur.

Guava RateLimiter'ı inceleyin veya kümelenmiş bir ortam için kendi jeton paketi algoritmanızı uygulayın. Örneğin, jetonları Redis veya Memcached gibi dağıtılmış, düşük gecikmeli bellek içi veri depolarında yönetebilirsiniz. Bu depolarda her istemci, bir isteği işlemeden önce bir jeton alır ve kullanır. Jetonlar biterse istemci, bir sonraki jeton grubu yenilenene kadar bekler.

Sıraya ekleme

Mesaj kuyruğu, işlem yükü dağıtımı için çözüm sunarken istek ve tüketici oranlarını da kontrol eder. Bazıları açık kaynaklı, bazıları tescilli olan ve çoğu farklı dillerle çalışabilen çeşitli mesaj sırası seçenekleri vardır.

Mesaj sıralarını kullanırken sıraya mesaj gönderen birden fazla üreticiniz ve bu mesajları işleyen birden fazla tüketiciniz olabilir. Kısıtlamalar, eşzamanlı tüketici sayısını sınırlayarak tüketici tarafında veya üreticiler ya da tüketiciler için sıklık sınırlayıcılar veya kısıtlayıcılar uygulayarak uygulanabilir.

Örneğin, bir mesaj tüketicisi sıklık sınırlaması hatasıyla karşılaşırsa isteği standart bir yeniden deneme gecikmesiyle (eksponansiyel geri yükleme kullanarak) sıraya döndürebilir ve paylaşılan bir sıklık sınırlayıcı geri bildirim döngüsünü güncelleyebilir. Böylece tüm tüketiciler hatadan kurtulurken işleme hızlarını otomatik olarak azaltır.