Gecikme (Latency)

Gecikme (latency), bir istek gönderildiğinde yanıtın ulaşması arasındaki süredir. Ağa bağlı sistemlerde milisaniye; dağıtık sistemlerde zaman zaman mikrosaniye; kullanıcının algıladığı gecikmede ise insanların fark etmeye başladığı yüzlerce milisaniye cinsinden ölçülür.

Her mühendisin bir servisin gecikmesi hakkında bilmesi gereken üç ölçüm:

• Ortalama gecikme. Genellikle yanıltıcıdır. Tek bir yavaş aykırı değer onu yukarı çeker.
• Medyan (p50) gecikme. Tipik isteğin deneyimi. Ortalamadan daha dürüst.
• Kuyruk gecikmeleri (p95, p99, p99.9). Yanıt sürelerinin 95., 99. ve 99,9. yüzdelikleri. p99, “isteklerin %1’i bundan daha yavaş” anlamına gelir. Kullanıcıya yönelik sistemlerde p99, şanssız kullanıcıların deneyimini yansıtır.

Kuyrukların neden önemli olduğu: ölçekte her kullanıcı eninde sonunda kuyruğa düşer. p50 100 ms, p99 5000 ms olan bir servis hızlı tipik performansa ve zaman zaman 5 saniyelik donmalara sahiptir. Bir oturumda 100 istek yapan kullanıcı büyük olasılıkla en az bir kez kuyruğa düşer.

Tipik bir HTTP isteğindeki gecikme kaynakları:

• DNS: ilk aramada 1-50 ms, önbellekte ~0.
• TCP el sıkışması: 1 gidiş-dönüş süresi (RTT).
• TLS el sıkışması: 1-2 ek RTT.
• Sunucu işleme: mikrosaniyeden saniyelere kadar değişken.
• Ağ yayılımı: NY-Chicago arası ~5 ms, NY-Londra ~70 ms, NY-Sydney ~150 ms. Alt sınır ışık hızıdır.

Gerçek dünya API performansı için yüzdelik dağılım, ortalamadan çok daha önemlidir. Yalnızca ortalama gecikmeyi raporlamak, izleme panolarının yanıltıcı olmasının klasik yollarından biridir.

p99’un “bozuk hissettiren” metriği neden olduğu: isteklerin %99’u 100 ms’nin altında olan ancak %1’i 5 saniye süren bir servis, yavaş yolu eninde sonunda kaçınılmaz olarak deneyimleyen her kullanıcıya bozuk hissettirir. Matematiksel hesap: tipik bir sayfa yüklemesi 50 arka uç çağrısı yapıyorsa ve p99 5 s ise, kullanıcının en az bir yavaş çağrıya çarpma olasılığı 1 − (0,99)⁵⁰ ≈ %40’tır. Neredeyse her diğer sayfa yüklemesi yavaştır. Medyanı iyileştirmek görünmezdir; p99’u kesmek algılanan performansı doğrudan iyileştirir. Google’ın SRE el kitabı bu ilkeyi kodladı (“kuyruk gecikmesi, gecikmenin ta kendisidir”) ve kural sektör geneline yayıldı. Referans: Dean & Barroso — Ölçekte Kuyruk (CACM, 2013).

Çalışma örneği: istek genelinde bütçe dağılımı

Hedef: ABD’li bir kullanıcı için ödeme sayfasında 200 ms p95. NY-Londra ışık hızı RTT’si kabaca 70 ms’dir; bu, herhangi bir transatlantik çağrı için tabandır. Tipik bir yelpaze: TLS + bağlantı yeniden kullanım tasarrufu için 50 ms, bölgesel DB okuması için 40 ms, üçüncü taraf ödeme yetkilendirmesi için 60 ms, HTML render için 20 ms, istemci tarafı hidrasyonu için 30 ms. Bunları saf toplarsak 200 ms çıkar — yeniden denemeler, GC duraklamaları veya gürültülü komşu artışları için sıfır boşluk bırakır. Düzeltme yapısal: ödeme çağrısını kritik yoldan çıkarmak (yönlendirme sonrasına ertelemek), DB okumayı kenarda 60 s önbelleğe almak ve TLS’i bağlantı kurulumuyla birleştirmek için HTTP/3 üzerinde QUIC kullanmak. Her biri kuyruktan 30-50 ms kazandırır.

Doğru biçimde enstrümanlandırma

Ortalamaya göre toplamak, ihtiyaç duyduğunuz dağılım şeklini atar. Ham zamanlamaları örnekleyin ya da HDR histogramlarını (Gil Tene’nin HdrHistogram kütüphanesi, çoğu dile taşınmıştır) kullanın; bunlar yüzdelikleri ucuz biçimde korur. Yüzdelikleri bölgeye, uç noktaya, sürüme göre hesaplayın — küresel p99’daki 5 ms’lik bir gerileme, tek bir bölgede 200 ms’lik gerileme anlamına gelebilir ama ortalama almak bunu maskeler. “Koordineli ihmal”e dikkat edin: bir sonraki isteği vermeden önce yavaş bir isteği bekleyen yük oluşturucular p99’u büyüklük mertebeleri kadar düşük tahmin eder. Ayrıca bkz. yüzdelik ve medyan. Protokol düzeyinde RTT dökümü için RFC 9000 QUIC belirtimi, el sıkışma gecikmesini önemli ölçüde azaltan 0-RTT ve 1-RTT bağlantı kurulumunu belgelemektedir.