AI ajanları aynı anda yeniden deneyince beklemek neden yetmiyor?

Dört istemci aynı süreyi beklerse birlikte geri gelir

Bir araç yoğunluk nedeniyle bekleme istiyor. Dört ajan aynı anda yanıt alıyor ve hepsi on saniye bekliyor. Tek bir çağrının günlüğünde davranış makul görünür; bütün çağrıları aynı çizelgeye koyduğunuzda dört tekrarın yine aynı anda başladığını görürsünüz. Bekleme eklemek yükün zaman içindeki dağılımını mutlaka değiştirmez. Birden çok istemciyi birlikte incelemek, tek çağrı denetiminde görünmeyen bu kümeyi ortaya çıkarır.

Bu yazıda dört bağımsız istemcinin yalnız birer okuma çağrısı için tekrar başlangıçlarını hesaplıyoruz. Hiçbir ağ isteği gönderilmez; bütün saatler ve gecikmeler sentetiktir. Bekleme süresine farklı ek gecikmeler koymanın aynı saniyedeki başlangıç sayısını nasıl değiştirdiğini göstereceğiz. Sonuç, gerçek servis performansı veya üretim kapasitesi ölçümü değildir. Çıktınız çağrı sayısı, başlangıç zamanı ve süre penceresini birlikte gösteren bir plan olacak.

En erken zaman ile son başlama sınırını ayırın

İstemciler en erken t=20’de yeniden başlayabilir. Bu sınırın nasıl bir yanıt alanından çıkarıldığı burada önceden doğrulanmış kabul edilir; başlık ayrıştırma çalışması yapmıyoruz. Son başlama sınırı t<30’dur. Pencere çağrının tamamlanma anını değil başlangıcını sınırlar. Aday zaman bu pencerenin dışında kalırsa gecikmeyi kısaltıp alt sınıra aykırı çağrı göndermek yerine o tekrar başlatılmaz.

AWS’nin üstel bekleme ve jitter açıklaması, yalnız bekleme süresini artırmanın çağrı kümelerini sürdürebildiğini ve farklı rastgele gecikmelerin başlangıçları yaymak için kullanılabildiğini gösterir. Burada o yazının performans deneyini tekrarlamıyoruz. Aşağıdaki ek gecikmeler önceden verilmiş öğretim değerleridir; gerçek rastgele örnekleme yapılmaz. Kullanılan alt sınır artı gecikme kuralı da AWS’deki Full Jitter algoritmasının birebir uygulaması değildir.Kaynak: AWS — Exponential backoff and jitter

Sabit beklemeyi farklı başlangıçlarla karşılaştırın

Sabit senaryoda hepsi t=20’de başlar. İkinci senaryoda ortak 20 alt sınırına sırasıyla 1, 3, 6 ve 8 saniye eklenir. Başlangıçlar 21, 23, 26 ve 28 olur; hepsi en erken zamanın sonrasındadır ve 30’dan küçüktür. Dört istemcinin tekrar bütçesi değişmez. Yalnız başlangıçların farklı anlara yayılması, toplam çağrı sayısının azaldığı anlamına gelmez.

Sayımlarda bir saniyelik [k,k+1) aralıklarını kullanıyoruz; başlangıçlar tam saniyedir. Bu zaman çözünürlüğünde ilk planın tepe değeri dört, ikincinin birdir. İkinci planda ortalama başlangıç daha geçtir: 98/4=24,5. Daha yayılmış başlangıçlar ile daha kısa bekleme aynı hedef değildir. Gerçek isteğin ne kadar süreceği verilmediği için eşzamanlı çalışan çağrı sayısını veya hizmetin ne kadar hızlanacağını bu tablodan hesaplayamayız.

Farklı gecikme çakışmayı garantiyle kaldırmaz

İkinci bir karşı örnekte dört istemcinin ek gecikmesinin de üç saniye olduğunu düşünün. Hepsi t=23’te başlar ve tepe yine dört olur. Rastgele seçim kullanılan gerçek bir sistemde aynı değerler veya aynı zaman aralığına düşen değerler oluşabilir. Bu nedenle jitter uygulanmasını çakışmasızlık garantisi diye raporlamayın. Etkiyi ölçmek için kullanılan dağılım, zaman çözünürlüğü ve gerçek iş yükü ayrıca gerekir.

Ek gecikme on saniye olursa aday başlangıç 30’dur. Pencere 30’u dışladığı için o tekrar başlatılmaz. Daha küçük sayı seçerek her durumda çağrı yapmayı zorunlu tutan bir kural verilmemiştir. Benzer şekilde alt sınıra eksi gecikme uygulayıp t=19’a gitmek bu sözleşmeyi bozar. Yayma politikası, sunucunun en erken zamanını veya toplam tekrar bütçesini ortadan kaldırmaz.

Birlikte okunabilen çağrı çizelgesi isteyin

A–D istemcileri t=10’da yanıt aldı; en erken tekrar t=20, son başlama t<30. Her biri en fazla bir bağımsız okuma tekrarı yapabilir. Sabit senaryoda tüm başlangıçlar 20. İkinci senaryoda ortak 20 üzerine 1,3,6,8 saniye ekle. Her başlangıcı, pencere kararını ve bir saniyelik [k,k+1) aralıklarındaki en yüksek başlangıç sayısını hesapla. Ortalamayı da göster. Gerçek çağrı, rastgele örnekleme veya performans kazancı iddia etme. Ek gecikme 10 olduğunda sınır kararını ayrıca yaz.

Çıktıda önce her satırın 20 alt sınırına uyduğunu, sonra 30’dan küçük olduğunu denetleyin. Tepe başlangıç sayısıyla toplam tekrar sayısını ayrı kontrol edin. Model ikinci senaryoda yalnız bir çağrı kaldığını söylüyorsa tepe değerini toplamla karıştırmıştır. Ortalama zamanın 24,5 olması da bütün çağrıların bu anda başlayacağı anlamına gelmez; dört ayrı başlangıcın aritmetik özetidir.

Sabit: 20/20/20/20; toplam 4, tepe başlangıç 4.
Verilmiş ek gecikmelerle: 21/23/26/28; toplam 4, tepe başlangıç 1, ortalama t=24,5.
Bütün başlangıçlar [20,30) içinde. Ek gecikme 10 olursa t=30 dışarıda; o tekrar başlatılmaz.
Bu çalışmada gerçek araç çağrısı 0.

İki istemci aynı gecikmeyi seçerse

Ek gecikmeleri 1, 1, 6 ve 8 olarak değiştirin. Tekrar sayısı, pencere içindeki başlangıçlar ve bir saniyelik aralıklardaki tepeyi yeniden hesaplayın. Sonra dört gecikmenin de üç olduğu karşı örnekle karşılaştırın. Böylece “jitter var” etiketinden ziyade gerçekten elde edilen çizelgeyi değerlendirmiş olursunuz.

Başlangıçlar 21/21/26/28. Toplam 4 tekrar, hepsi pencere içinde; tepe başlangıç sayısı 2. Dört ek gecikme de 3 olsaydı 23/23/23/23 ve tepe 4 olurdu. Başlangıçların yayılması belirli seçilen değerlere bağlıdır.

Kendi akışınızda tekrar çizelgesini çağrı kimliği ve görev bütçesiyle birlikte tutun. Bir çağrının doğru beklemesiyle bütün istemcilerin uygun dağılımda çalışması farklı kontrollerdir. Bu örneği eğitimde kullanırken bekleme maliyetini de açık bırakın; daha geç başlamak gerçek işte kabul edilebilir mi sorusu ayrıca yanıtlanmalıdır. Sayısal plan, bu kararı verecek ekibe ortak bir zaman çizelgesi sunar.