429 yanıtı CPU yetersizliği anlamına gelmez
API isteğinin reddedilmesiyle isteği gönderen makinenin yavaş olması farklı belirtilerdir. Entegrasyonunuzda önce hangi işlem çağrısının hata verdiğini, satıcı hesabını ve zaman aralığını kaydedin. Bütün istekleri aynı genel hata etiketi altında toplarsanız yanlışlıkla sunucu yükseltmesine bütçe ayırabilirsiniz.
Amazon'un kullanım planı belgesi, çağrıların işlem, uygulama, hesap ve ilgili bölge gibi etkenlerle sınırlandırılabildiğini açıklıyor. Kullanılan token bucket yaklaşımında anlık birikim kapasitesi ile sürdürülebilir çağrı hızı aynı kavram değildir. Bu yüzden kısa bir başarılı seri, aynı hızın sürekli kullanılabileceğini kanıtlamaz.
Tek merkezi kuyruk yerine işlem sınıflarını görün
Sipariş okuma, katalog kontrolü ve arka plan rapor işleri için hangi çalışanların çağrı yaptığını çıkarın. Farklı servisler aynı hesap adına bağımsız tekrar deniyorsa toplam yük gözden kaçabilir. Operasyonları ayrı izleyip ortak sınırları dikkate alan bir kuyruk düzeni planlayın.
Kritik işlerin arkasına gereksiz sık kontrol çağrıları eklemeyin. Değişmeyen bir kaydı her turda tekrar okumak yerine iş ihtiyacına uygun kontrol sıklığını belirleyin. Burada amaç Amazon sınırını aşmak değil, izin verilen kapasiteyi gereksiz işlerle tüketmemektir.
Tekrar denemeyi bir iş kuralına bağlayın
Anında ve sınırsız tekrar denemek yoğunluğu artırabilir. Geliştiricinizle sınırlı deneme sayısı, bekleme aralığı ve başarısız işlerin inceleneceği ayrı alan belirleyin. Yanıtın hangi hata sınıfına ait olduğunu ayırmadan bütün hataları aynı döngüde tekrar çalıştırmayın.
Yazma işlemlerinde yeniden denemenin aynı sonucu ikinci kez oluşturup oluşturmadığını ayrıca inceleyin. Zaman aşımı, işlemin kesinlikle yapılmadığını göstermez. İş kimliği, gönderilen değişiklik ve son doğrulama sonucu kaydedilirse belirsiz işler güvenli biçimde araştırılabilir.
Başarıyı yalnız hata sayısıyla ölçmeyin
Kuyruk yaşı, tamamlanan iş sayısı ve bekleyen önemli kayıtlar birlikte izlenmeli. Hata sayısının düşmesi bazen çalışanların tamamen durduğu anlamına da gelebilir. Bu nedenle ölçüm panosunda son başarılı işlem zamanını ve beklenen veri güncelliğini görünür tutun.
Yük arttığında önce hangi dar boğazın değiştiğini tespit edin. Kuyruk yavaşlığı API sınırından mı, veritabanından mı, bağlantıdan mı kaynaklanıyor? Sunucu kaynakları ancak yerel ölçümler bunu destekliyorsa artırılmalı; yeni IP veya hesaplarla sınırlamayı aşma yaklaşımı kullanılmamalı.
İş planına düşük öncelikli görevleri durdurma seçeneği ekleyin. Örneğin kritik sipariş kuyruğu birikmişken isteğe bağlı katalog taramasını sürdürmek uygun olmayabilir. Hangi görevin ertelenebileceği teknik ekip tarafından tek başına değil, verinin iş üzerindeki etkisini bilen sorumlu kişiyle birlikte kararlaştırılmalı.
Entegrasyonun çalıştığı ortam için Amazon VDS seçeneklerini ihtiyaçla karşılaştırabilirsiniz. rapor erişim sorunları; sunucu izleme planı; yedekleme planı rehberleri de iş akışını tamamlar. Sunucu kaynağı, Amazon'un uyguladığı izin veya API kullanım sınırlarının yerine geçmez.
Sıkça Sorulan Sorular
429 görünce daha yüksek RAM almak çözer mi?
Tek başına çözmez. Önce ilgili API işleminin kullanım planını ve uygulamanın toplam çağrı düzenini inceleyin.
Hata veren her isteği yeniden göndermeli miyim?
Hayır. Hata sınıfını, tekrar sınırını ve yazma işleminin olası etkisini değerlendiren bir politika gerekir.
Sadece başarılı istek sayısını izlemek yeterli mi?
Hayır. Kuyrukta ne kadar eski iş beklediği ve son başarılı veri güncellemesi de önemlidir.
Her API işlemi aynı sınırı mı kullanır?
Bunu varsaymayın. İşlemin güncel referansını ve uygulanan kullanım planını ayrı kontrol edin.