Bu bölüm metnini Türkçeye çevir. Anlam aynı kalsın. İngilizce cümle bırakma.
Çoğu uygulamayı laboratuvar testlerinde geçirip, gerçek kullanıcılar tahmin edilemez bağlantılara girdiğinde çöktüğünü gördüm. Çözüm? Tahmin etme—simülasyon yap. Ortamımda, herhangi bir şey üretime dokunmadan önce test trafiğine kontrollü gecikme, jitter ve paket kaybı enjekte etmek için Linux tc netem kullanıyorum. Şeyleri kırmanın değil, nerede ilk kez kırılacağını bulmanın amacı var.
Test trafiğinizi taşıyan arayüzü belirleyerek başlayın. Genellikle test makinenizde bir veth çifti, köprü veya ayrık NIC olur. ip link show komutunu çalıştırarak onaylayın. Cihazı biliyorsanız—diyelim eth1—onu şekillendirebilirsiniz.
Öncelikle değişkenli bir temel gecikme ekleyin. Bu, gerçek WAN’da RTT’nin sabit olmadığını taklit eder:
sudo tc qdisc add dev eth1 root netem delay 100ms 30ms distribution normalBurada, 100ms ortalama gecikme, 30ms standart sapma (jitter) ve normal dağınık Gauss dağılımı sağlar—uniform rastgeleden çok daha gerçekçi. Çoğu paket 100ms±30ms civarında kümeleşir, nadir outlier’lar olur. Bu, gerçek genişbant veya mobil bağlantıların hissedildiği şekildir.
Doğrulamak için başka bir host’tan ping atın:
ping -c 10 192.168.100.5min/avg/max/mdev satırına bakın. mdev (ortalama sapma) jitter değerinizin yakınında fluctuate etmelidir. Çok düşükse, jitter parametresini artırın; çok yüksekse, yanlış pozitiflere yol açarsınız.
Bazen kayıp da gerekir—özellikle zaman aşımı veya yeniden deneme testi yaparken. Gecikme ve kaybı birleştirin:
sudo tc qdisc change dev eth1 root netem delay 100ms 30ms loss 2%Şimdi %2’lik paketler, jitterli gecikme üzerine düşürülür. Bu kombinasyon, mikro hizmetlerde bağlantıların donması, sağlık kontrollerinin başarısız olması veya zincirleme zaman aşımı gibi sorunları ortaya çıkarır.
Burst kayıp testi yapmak ister misiniz? Korelasyon seçeneğini kullanın:
sudo tc qdisc change dev eth1 root netem delay 100ms 30ms loss 2% 25%İkinci kayıp yüzdesi, bir paketin kaybı ardından başka bir paketin de kaybolma olasılığını belirler—bu da patlama gibi kayıplar oluşturur. Bu, gerçek kablosuz veya tıkanık bağlantılara daha yakın ve daha zorlayıcı bir senaryodur.
İşiniz bittiğinde, qdisc’i temizleyin:
sudo tc qdisc del dev eth1 rootHer zaman temizleme yapın. Netem’i bir geliştirme arayüzünde bırakmak, saatler sonra arkadaşlarınızı kafayı yeme duruma getirebilir.
API gateway değişiklikleri veya veritabanı geçiş betiklerini çıkarmadan önce bunu kullanırım. Daha önce Argo Rollouts’taki latency SLO’larımdaki yazımda da belirttiğim gibi, gecikme simülasyonu, yalnızca hata oranına dayanmaktan daha iyi SLO-tabanlı kanary’leri doğrular. Uygulamanız 150ms p95 gecikmeyle jitter altında zarif şekilde düşerse, gerçek bir WAN titreşimini daha büyük olasılıkla aşar.
Bir uyarı: netem çekirdek üzerinden ek yük getirir. Yoğun test makinelerinde CPU’yu izleyin—özellikle gigabit+ trafik shaping yapıyorsanız. Yüksek hızlarda, önce tc ile htb kullanarak hız sınırlaması yapıp, üstüne netem eklemek için ayrılmış bir cihaz düşünebilirsiniz.
Tekrarlanan testler için betikler yazırım. Basit bir bash fonksiyonu, tc komutlarını sarmalar, arayüz, gecikme, jitter, kayıp gibi argümanları alır ve çıkışta temizliği sağlar. Bu fonksiyonu test paketinizle birleştirin—simülasyonu çalıştırın, uygulamaya yük uygulayın, ardından devre dışı bırakın.
Bu, mükemmel fideliği yakalamakla ilgili değil. Belirgin fragilizeleri erken yakalamaktır: sabit zaman aşımları, eksik yeniden denemeler, LAN hızlarını varsayılan UI zaman aşımları. Uygulamanız 200ms RTT ve 50ms jitter ile çalışıyorsa, çoğu şube ofisi veya uzak kullanıcı senaryosunu karşılayacaktır. Orada test edin—önce.
Kapak görseli: Unknown · CC0 (Openverse / kamu malı) · https://www.rawpixel.com/image/6038427/photo-image-public-domain-technology-line