Google Play EMM API'nin her EMM için varsayılan sınırı dakikada 60.000 sorgudur.
Kotayı aşarsanız Google Play EMM API HTTP 429 Too Many Requests
değerini döndürür.
Belirtilen kullanım sınırlarını aşmamanız ve kullanıcılarınıza en iyi deneyimi sunmanız için aşağıdaki bölümde açıklanan en iyi uygulamalardan bazılarını uygulamayı düşünebilirsiniz.
API kullanım sınırlarının altında kalma önerileri
Google Play EMM API'yi kullanırken istekleri dağıtmak ve kullanım sınırlarını aşma riskinizi azaltmak için uygulayabileceğiniz bazı en iyi uygulamalar vardır.
Başlangıç zamanlarını ve aralıkları rastgele belirleme
Cihazları aynı anda senkronize etme veya giriş yapma gibi işlemler, istek hacminde önemli bir artışa neden olabilir. Bu etkinlikleri düzenli olarak planlanmış aralıklarla gerçekleştirmek yerine, bu aralıkları rastgele ayarlayarak istek yükünüzü dağıtabilirsiniz. Örneğin, her cihazı 24 saatte bir senkronize etmek yerine 23 ile 25 saat arasında rastgele seçilen bir zaman diliminde senkronize edebilirsiniz. Bu, istek sayısının dağıtılmasına yardımcı olur.
Benzer şekilde, kısa süre içinde art arda birçok API çağrısı yapan günlük bir iş çalıştırırsanız tüm kurumsal müşterileriniz için aynı anda çok sayıda istek yapılmasını önlemek amacıyla işi her gün rastgele bir zamanda başlatabilirsiniz.
İstekleri yeniden denemek için eksponansiyel geri yükleme kullanın
Birçok API çağrısından oluşan işler çalıştırırsanız kotaya ulaşıldığında yanıt olarak eksponansiyel geri yükleme stratejisi kullanın. Üstel geri yükleme, istekleri katlanarak yeniden deneyen bir algoritmadır. Basit eksponansiyel geri yükleme uygulamak için örnek bir akış aşağıda verilmiştir:
- Google Play EMM API'ye istek gönderin.
HTTP 429
yanıtı alın.- 2 saniye +
random_time
bekleyip isteği yeniden deneyin. HTTP 429
yanıtı alırsınız.- 4 saniye +
random_time
bekleyip isteği yeniden deneyin. HTTP 429
yanıtı alın.- 8 saniye +
random_time
bekleyip isteği yeniden deneyin.
random_time
genellikle -0,5 * bekleme süresi ile +0,5 * bekleme süresi arasında değişen rastgele bir sayıdır. İsteğinizi her yeniden denediğinizde yeni bir random_time
yeniden tanımlayın. Kullanıcılara yönelik işlemleri tamamlamak için gereken API çağrıları, daha sık bir planlamayla (ör.0, 5 sn, 1 sn ve 2 sn) yeniden denenebilir.
Toplu işlemleri hız sınırla
Toplu bir işlem kotaya her ulaştığında API'yi çağıran kullanıcı işlemlerinin gecikmesi artar. Bu gibi durumlarda üstel geri çekilme gibi stratejiler, kullanıcı işlemleri için düşük gecikmeyi korumada yeterince etkili olmayabilir.
API'nin kullanım sınırlarına sürekli olarak ulaşılmasını ve kullanıcılara yönelik işlemlerde gecikmenin artmasını önlemek için toplu işlemleriniz için bir hız sınırlayıcı kullanmayı düşünün (Google'ın RateLimiter bölümünü inceleyin). Hız sınırlayıcı ile API isteklerinizin hızını sürekli olarak kullanım sınırlarının altında kalacak şekilde ayarlayabilirsiniz.
Örneğin, varsayılan hız sınırı 50 QPS'lik bir toplu işlem başlatın. API hata döndürmediği sürece hız sınırını yavaşça artırın (her dakika% 1). Kotaya her ulaştığınızda istek oranınızı %20 azaltın. Bu uyarlanabilir yaklaşım, kullanıcılara yönelik işlemlerde gecikmeyi azaltırken daha optimal bir istek hızına yol açar.